File editing system and shared file editing system with file content secrecy, file version management, and asynchronous editing

ABSTRACT

A file editing system that provides a high file content secrecy, a file version management and an asynchronous editing is disclosed. For a high file content secrecy, the block data of files managed by a file management server device are enciphered in units of blocks, and a client device obtains the block data of the desired file in enciphered state, deciphers the obtained block data in units of blocks, carries out an editing of the desired file to obtain editing data, enciphers the editing data in units of blocks, and transmits the enciphered editing data to the file management server device. For asynchronous editing, the system includes a unit for generating editing procedure data that indicates a procedure to obtain the editing made in the desired version of the desired file by each client device, a unit for converting the editing procedure data for the desired version of the converted desired file into the editing procedure data for the latest version of the desired file, and a unit for generating record management information indicating a result of the editing made by each client device according to the converted editing procedure data for the latest version of the desired file.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates to a file editing system forrealizing asynchronous editing of a shared file by a plurality of usersand a file content reading protection in a computer based shared filesystem or database system.

[0003] 2. Description of the Background Art

[0004] In a computer system, in order to manage the accesses from aplurality of users with respect to a resource within the system, it hasbeen pointed out that it is necessary to provide an authenticationmechanism for confirming whether a user issuing an access request is aproper user who has an access right with respect to that resource ornot. In particular, under an environment of a large scale system inwhich an access from a remote user is permitted, such an authenticationmechanism becomes very important. A representative conventional systemfor realizing such an authentication mechanism is the Kerberos.

[0005] A typical conventional system which requires such anauthentication mechanism is the CSCW (Computer Supported CooperativeWork). The CSCW is a generic name for computer systems which assist thecooperative work of a plurality of users, and the shared file system isits most basic and typical example. In the shared file system, aplurality of users have access rights such as “read” and “write” withrespect to the identical file, and the system can realize the editingwork without causing any contradiction while allowing the accesses bythese users with respect to the identical file simultaneously.

[0006] Conventionally, a general format for realizing such a shared filesystem has been the client server type in which the client as a subjectwhich makes accesses to the files and the server which manages the filesare separated, and the authentication system for carrying out theauthentication of the accesses from the client is implemented therein.That is, the server authenticates the proper access right of the client,and if necessary, the server also carries out the enciphering of thedata to be transmitted between the client, while the clientauthenticates the properness of the connected server. Conventionallyknown examples of such a shared file system include the Lotus Notes.There is also a system called CFS (Cryptographic File System) which isknown as an example of a file system in which the enciphering of thefile contents can be carried out by the cliet.

[0007] As this type of a shared file system becomes more wide ranging inits service, it can be expected that there arises a need for a serviceformat in which only a file server is required at a certain site.Namely, it is a format in which the file management and the accessmanagement are provided, but the file contents cannot be read out at theserver itself. However, this type of service cannot be realized by usingthe conventional security system because the conventional securitysystem only protects the communication data and the file contents at theserver are managed in forms of plain texts.

[0008] Also, in the conventional mechanism for realizing thesimultaneous editing on the shared file, while one user is carrying outthe editing which uses the writing with respect to a certain file, whatthe other users can do with respect to the same file is restricted tothe reading at best. Thus, this is not a real simultaneous editingstrictly speaking, and it is merely realizing a synchronous editing inwhich the synchronization is made by utilizing the locking mechanism soas to avoid the contradiction among the accesses from a plurality ofusers. Namely, while the first access requesting user makes an access,the locking mechanism is activated such that the file access request forwriting from the other user is not permitted, and the other user isforced to suspend the file access temporarily, await for the release ofthe lock, and try the file access again after the lock is released.

[0009] In this regard, a more flexible system can be realized if it ispossible to allow one user to carry out the editing which uses thewriting with respect to a certain file even when the other user iscarrying out the editing which uses the writing with respect to the samefile. In the following, this type of operation will be referred asasynchronous editing in a sense that there is no need to make thesynchronization among the accesses which are randomly generated by aplurality of users.

[0010] On the other hand, another technique related to the shared filesystem is the version management technique. The conventionally knownversion management schemes include the SCCS (Source Code Control System)and the RCS (Revision Control System). Such a version management schemeachieves the compression of the file size by maintaining only adifference between different versions instead of maintaining the filesat a given moment entirely, in a circumstance such as that of a programdevelopment by a plurality of programmers. However, despite of itsadvantage regarding the reduced file size, its incorporation into theshared file system has been limited so far to a case of the synchronousediting using the locking mechanism.

SUMMARY OF THE INVENTION

[0011] It is therefore an object of the present invention to provide afile editing system capable of realizing a higher level of secrecy suchthat the file contents cannot be read from the file server.

[0012] It is another object of the present invention to provide a sharedfile editing system which supports the file version management, which iscapable of realizing the asynchronous editing.

[0013] It is another object of the present invention to provide a sharedfile editing system which supports the file version management, which iscapable of realizing the asynchronous editing while keeping the filecontents secret from the file server.

[0014] According to one aspect of the present invention there isprovided a file editing system, comprising: a file management serverdevice for managing files, each file containing a plurality of blockdata and block identification information for each block data, the blockdata being enciphered in units of blocks, and the file management serverdevice managing the files according to the block identificationinformation for each block data; and at least one client device, whichmakes an access to the file management server device to obtain the blockdata belonging to a desired file managed by the file management serverdevice, the client device including: deciphering means for decipheringthe block data obtained from the file management server device, in unitsof blocks by using a prescribed decipher key; editing means for editingthe desired file formed by the block data deciphered by the decipheringmeans to obtain editing data indicating an editing made in the desiredfile; enciphering means for enciphering the editing data obtained by theediting means, in units of blocks by using a prescribed cipher key, toobtain enciphered editing data; and communication means for transmittingthe enciphered editing data obtained by the enciphering means to thefile management server device, such that the file management serverdevice manages the desired file according to the enciphered editing datareceived from the client device.

[0015] According to another aspect of the present invention there isprovided a file editing system, comprising: a file management serverdevice for managing files, each file containing a plurality of blockdata and block identification information for each block data, and theblock data being enciphered in units of blocks; and at least one clientdevice, which makes an access to the file management server device toobtain the block data corresponding to a desired version of a desiredfile managed by the file management server device, the client deviceincluding: deciphering means for deciphering the block data obtainedfrom the file management server device, in units of blocks by using aprescribed decipher key; editing means for editing the desired versionof the desired file formed by the block data deciphered by thedeciphering means; editing procedure generation means for generatingediting procedure data indicating a procedure to obtain an editing madein the desired version of the desired file by the editing means; editingprocedure conversion means for converting the editing procedure data forthe desired version of the desired file generated by the editingprocedure generation means into editing procedure data for a latestversion of the desired file; record management information generationmeans for generating record management information indicating a resultof the editing made by the editing means, according to the editingprocedure data for the latest version of the desired file obtained bythe editing procedure conversion means; enciphering means forenciphering the record management information generated by the recordmanagement information generation means, in units of blocks by using aprescribed cipher key, to obtain enciphered record managementinformation; and communication means for transmitting the encipheredrecord management information obtained by the enciphering means to thefile management server device; wherein the file management server deviceincludes: record management means for carrying out a record managementof the desired file according to the enciphered record managementinformation received from the client device and the block identificationinformation for each block data.

[0016] According to another aspect of the present invention there isprovided a file editing system, comprising: a file management serverdevice for managing files, each file containing a plurality of blockdata and block identification information for each block data; and atleast one client device, which makes an access to the file managementserver device to obtain the block data corresponding to a desiredversion of a desired file managed by the file management server device,the client device including: deciphering means for deciphering the blockdata obtained from the file management server device, by using aprescribed decipher key; editing means for editing the desired versionof the desired file formed by the block data deciphered by thedeciphering means; editing procedure generation means for generatingediting procedure data indicating a procedure to obtain an editing madein the desired version of the desired file by the editing means andincluding insertion data to be inserted into the desired file;enciphering means for enciphering the insertion data included in theediting procedure data generated by the editing procedure generationmeans, by using a prescribed cipher key, to obtain enciphered editingprocedure data; and communication means for transmitting the encipheredediting procedure data obtained by the enciphering means to the filemanagement server device; wherein the file management server deviceincludes: editing procedure conversion means for converting theenciphered editing procedure data for the desired version of the desiredfile received from the client device into enciphered editing proceduredata for a latest version of the desired file; record managementinformation generation means for generating record managementinformation indicating a result of the editing made by the editingmeans, according to the enciphered editing procedure data for the latestversion of the desired file obtained by the editing procedure conversionmeans; and record management means for carrying out a record managementof the desired file according to the record management informationobtained by the record management information generation means and theblock identification information for each block data.

[0017] According to another aspect of the present invention there isprovided a shared file editing system, comprising: a file managementserver device for managing files, each file containing a plurality ofblock data and block identification information for each block data; aplurality of client devices, each client device making an access to thefile management server device to obtain the block data corresponding toa desired version of a desired file managed by the file managementserver device, and editing the desired file formed by the block dataobtained from the file management server device; and asynchronousediting support means for supporting asynchronous editing by saidplurality of client devices, including: editing procedure generationmeans for generating editing procedure data indicating a procedure toobtain each editing made in the desired file by each client device;editing procedure conversion means for converting the editing proceduredata for the desired version of the desired file generated by theediting procedure generation means into editing procedure data for alatest version of the desired file; and record management informationgeneration means for generating record management information indicatinga result of the editing made in the desired file by each client device,according to the editing procedure data for the latest version of thedesired file obtained by the editing procedure conversion means, suchthat the file management server device manages the desired fileaccording to the record management information and the blockidentification information for each block data.

[0018] According to another aspect of the present invention there isprovided a method of file editing in a file editing system formed by afile management server device and at least one client device, comprisingthe steps of: managing files at the file management server device, eachfile containing a plurality of block data and block identificationinformation for each block data, the block data being enciphered inunits of blocks, and the file management server device managing thefiles according to the block identification information for each blockdata; making an access to the file management server device to obtainthe block data belonging to a desired file managed by the filemanagement server device, at the client device; deciphering the blockdata obtained from the file management server device, in units of blocksby using a prescribed decipher key, at the client device; editing thedesired file formed by the block data deciphered by the deciphering stepto obtain editing data indicating an editing made in the desired file,at the client device; enciphering the editing data obtained by theediting step, in units of blocks by using a prescribed cipher key, toobtain enciphered editing data at the client device; and transmittingthe enciphered editing data obtained by the enciphering step from theclient device to the file management server device, such that the filemanagement server device manages the desired file according to theenciphered editing data received from the client device.

[0019] According to another aspect of the present invention there isprovided a method of file editing in a file editing system formed by afile management server device and at least one client device, comprisingthe steps of: managing files at the file management server device, eachfile containing a plurality of block data and block identificationinformation for each block data, and the block data being enciphered inunits of blocks; making an access to the file management server deviceto obtain the block data corresponding to a desired version of a desiredfile managed by the file management server device, at the client device;deciphering the block data obtained from the file management serverdevice, in units of blocks by using a prescribed decipher key, at theclient device; editing the desired version of the desired file formed bythe block data deciphered by the deciphering step, at the client device;generating editing procedure data indicating a procedure to obtain anediting made in the desired version of the desired file by the editingstep, at the client device; converting the editing procedure data forthe desired version of the desired file generated by the editingprocedure data generating step into editing procedure data for a latestversion of the desired file, at the client device; generating a recordmanagement information indicating a result of the editing made at theediting step, according to the editing procedure data for the latestversion of the desired file obtained by the converting step, at theclient device; enciphering the record management information generatedby the record management information generating step, in units of blocksby using a prescribed cipher key, to obtain enciphered record managementinformation at the client device; and transmitting the enciphered recordmanagement information obtained by the enciphering step from the clientdevice to the file management server device; carrying out a recordmanagement of the desired file at the file management server device,according to the enciphered record management information received fromthe client device and the block identification information for eachblock data.

[0020] According to another aspect of the present invention there isprovided a method of file editing in a file editing system formed by afile management server device and at least one client device, comprisingthe steps of: managing files at a file management server device, eachfile containing a plurality of block data and block identificationinformation for each block data; making an access to the file managementserver device to obtain the block data corresponding to a desiredversion of a desired file managed by the file management server device,at the client device; deciphering the block data obtained from the filemanagement server device, by using a prescribed decipher key, at theclient device; editing the desired version of the desired file formed bythe block data deciphered by the deciphering step, at the client device;generating editing procedure data indicating a procedure to obtain anediting made in the desired version of the desired file by the editingstep and including insertion data to be inserted into the desired file,at the client device; enciphering the insertion data included in theediting procedure data generated by the editing procedure datagenerating step, by using a prescribed cipher key, to obtain encipheredediting procedure data at the client device; transmitting the encipheredediting procedure data obtained by the enciphering step from the clientdevice to the file management server device; converting the encipheredediting procedure data for the desired version of the desired filereceived from the client device into enciphered editing procedure datafor a latest version of the desired file, at the file management serverdevice; generating record management information indicating a result ofthe editing made by the editing step, according to the encipheredediting procedure data for the latest version of the desired fileobtained by the converting step, at the file management server device;and carrying out a record management of the desired file at the filemanagement server device, according to the record management informationobtained by the record management information generating step and theblock identification information for each block data.

[0021] According to another aspect of the present invention there isprovided a method of shared file editing in a shared file editing systemformed by a file management server device and a plurality of clientdevices, comprising the steps of: managing files at the file managementserver device, each file containing a plurality of block data and blockidentification information for each block data; making an access to thefile management server device to obtain the block data corresponding toa desired version of a desired file managed by the file managementserver device, at each client device; editing the desired file formed bythe block data obtained from the file management server device, at eachclient device; generating editing procedure data indicating a procedureto obtain an editing made in the desired file by each client device atthe editing step; converting the editing procedure data for the desiredversion of the desired file generated at the editing procedure datagenerating step into editing procedure data for a latest version of thedesired file; and generating record management information indicating aresult of the editing made in the desired file by each client device atthe editing step, according to the editing procedure data for the latestversion of the desired file obtained by the converting step, such thatthe file management server device manages the desired file according tothe record management information and the block identificationinformation for each block data.

[0022] Other features and advantages of the present invention willbecome apparent from the following description taken in conjunction withthe accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023]FIG. 1 is a schematic diagram of an overall configuration of thefirst embodiment of a shared file editing system according to thepresent invention.

[0024]FIG. 2 is a diagram for explaining a file data structure in adifference pile up scheme that can be used in the system of FIG. 1 as arecord management scheme.

[0025]FIG. 3 is a diagram for explaining a file data structure in an RCSscheme that can be used in the system of FIG. 1 as a record managementscheme.

[0026]FIG. 4 is a diagram for explaining a file data structure in amodified SCCS scheme that can be used in the system of FIG. 1 as arecord management scheme.

[0027]FIG. 5 is a block diagram of an asynchronous editing system to beincorporated into the system of FIG. 1.

[0028]FIG. 6 is a diagram for explaining a manner of record managementin the asynchronous editing system of FIG. 5 for a case of using thedifference pile up scheme of FIG. 2.

[0029]FIG. 7 is a diagram for explaining a manner of record managementin the asynchronous editing system of FIG. 5 for a case of using themodified SCCS scheme of FIG. 4.

[0030]FIG. 8 is a diagram for explaining an OFB mode stream cipherscheme that can be used in the system of FIG. 1 as a file data cipherscheme.

[0031]FIG. 9 is a diagram for explaining a CFB mode stream cipher schemethat can be used in the system of FIG. 1 as a file data cipher scheme.

[0032]FIG. 10 is a diagram for explaining a cipher procedure in thesystem of FIG. 1 at a time of block data division.

[0033]FIG. 11 is a flow chart of a cipher procedure in the system ofFIG. 1 at a time of block data division for a case of using the firstcipher scheme.

[0034]FIG. 12 is a flow chart of a cipher procedure in the system ofFIG. 1 at a time of block data division for a case of using the secondcipher scheme.

[0035]FIG. 13 is a block diagram of a first exemplary configuration inthe second embodiment of a shared file editing system according to thepresent invention.

[0036]FIG. 14 is a block diagram of a shared file editing unit in thesystem of FIG. 13.

[0037]FIG. 15 is a block diagram of a cipher unit in the system of FIG.13.

[0038]FIG. 16 is a block diagram of a second exemplary configuration inthe second embodiment of a shared file editing system according to thepresent invention.

[0039]FIG. 17 is a block diagram of a shared file editing unit in thesystem of FIG. 16.

[0040]FIG. 18 is a block diagram summarizing main features in the firstexempary configuration of FIG. 13. FIG. 19 is a block diagramsummarizing main features in the second exempary configuration of FIG.16. FIG. 20 is a block diagram of the third embodiment of a shared fileediting system according to the present invention.

[0041]FIG. 21 is a block diagram of a shared file editing unit in thesystem of FIG. 20.

[0042]FIG. 22 is a block diagram of a merge processing unit in thesystem of FIG. 20.

[0043]FIG. 23 is a block diagram of the fourth embodiment of a sharedfile editing system according to the present invention.

[0044]FIG. 24 is a block diagram of a cipher unit in the system of FIG.23.

[0045]FIG. 25 is a block diagram of the fifth embodiment of a sharedfile editing system according to the present invention.

[0046]FIG. 26 is a block diagram of a client counting unit in the systemof FIG. 25.

[0047]FIG. 27 is a diagram for explaining an exemplary data structurefor a count memory unit in the client counting unit of FIG. 26.

[0048]FIG. 28 is a flow chart for an operation of a deletion requestprocessing unit in the client counting unit of FIG. 26.

[0049]FIG. 29 is a flow chart for an operation of an editing endprocessing unit in the client counting unit of FIG. 26.

[0050]FIG. 30 is a flow chart for a deletion command executionprocessing by a record management unit in the system of FIG. 25 for acase of using the difference pile up scheme of FIG. 2.

[0051]FIG. 31 is a flow chart for a deletion command executionprocessing by a record management unit in the system of FIG. 25 for acase of using the RCS scheme of FIG. 3.

[0052]FIG. 32 is a flow chart for a deletion command executionprocessing by a record management unit in the system of FIG. 25 for acase of using the modified SCCS scheme of FIG. 4.

[0053]FIG. 33 is a block diagram of the sixth embodiment of a sharedfile editing system according to the present invention.

[0054]FIG. 34 is a flow chart for an operation of a block datareconstruction unit in the system of FIG. 33 during a deletion commandexecution processing in the system of FIG. 33 for a case of using thedifference pile up scheme of FIG. 2.

[0055]FIG. 35 is a flow chart for an operation of a record managementunit in the system of FIG. 33 during a deletion command executionprocessing in the system of FIG. 33 for a case of using the differencepile up scheme of FIG. 2.

[0056]FIG. 36 is a flow chart for an operation of a block datareconstruction unit in the system of FIG. 33 during a deletion commandexecution processing in the system of FIG. 33 for a case of using theRCS scheme of FIG. 3.

[0057]FIG. 37 is a flow chart for an operation of a record managementunit in the system of FIG. 33 during a deletion command executionprocessing in the system of FIG. 33 for a case of using the RCS schemeof FIG. 3.

[0058]FIG. 38 is a block diagram of the seventh embodiment of a sharedfile editing system according to the present invention.

[0059]FIG. 39 is a flow chart for an operation of a differenceinformation construction unit in the system of FIG. 38 for a case ofusing the modified SCCS scheme of FIG. 4.

[0060]FIG. 40 is a block diagram of the eighth embodiment of a sharedfile editing system according to the present invention.

[0061]FIG. 41 is a block diagram of the ninth embodiment of a sharedfile editing system according to the present invention.

[0062]FIG. 42 is a block diagram of the tenth embodiment of a sharedfile editing system according to the present invention.

[0063]FIG. 43 is a diagram of an exemplary access record list used by anaccess information memory unit in the system of FIG. 42.

[0064]FIG. 44 is a block diagram of the eleventh embodiment of a sharedfile editing system according to the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0065] Now, the first embodiment of a shared file editing systemaccording to the present invention will be described in detail.

[0066] This shared file editing system of the first embodimentincorporates two independently realizable features of the presentinvention. The first feature concerns with a provision for making itimpossible to read out file contents from a file server in a shared fileediting system which manages files in blocks, while the second featureconcerns with a provision for making it possible to carry out theasynchronous editing operation in a shared file editing system whichsupports the file version management.

[0067] In this First embodiment, the shared file editing system has ageneral configuration as shown in FIG. 1, which comprises one or aplurality of access requesting clients 101 (referred hereafter simply asclients) which issue file access requests with respect to shared files,and a file management server 110 (referred hereafter simply as a server)for carrying out the management of the files and the communication ofrequested data with respect to the clients 101. Here, between eachclient 101 and the server 110, there is provided a communication path111 for transmitting and receiving request messages and responsemessages.

[0068] Here, the client 101 is an abstraction of a concept encompassinga user who issued the actual access request, a process on a computerused by that user, etc. Also, as shown in FIG. 1, each client 101 isequipped with a cipher unit 112 for carrying out the enciphering anddeciphering operations. As will be described in detail below, thiscipher unit 112 further includes an encipher/decipher processing unitfor executing the cipher algorithm, and a key memory unit for storing acipher key and a decipher key. Further details concerning functions ofthese encipher/decipher processing unit and the key memory unit will bedescribed later on.

[0069] On the other hand, the server 110 may be a process on a computerfor carrying out the file management, or an independent device havingthe file management function.

[0070] The communication path 111 can be any media which can exchangemessages electronically, such as public network, LAN, Ethernet, orcommunication using sockets within a computer

[0071] The server 110 is managing a plurality of files 113. Here, thefiles 113 contain not Just data which represent the file contents, butalso an information for record management, a list of user names for whomthe accesses are allowed, an information utilized in encipher/decipherprocessing, etc. which will be described in detail later on. These files113 are enciphered in a format which can be deciphered only by therespective proper clients 101.

[0072] In a case of utilizing a usual cipher scheme in which the cipherkey and the decipher key are identical, the proper client 101 possessesthat identical key, by means of which the files 113 can be enciphered ordeciphered.

[0073] Now, the file 113 has a property that its content is changingfrom time to time as a result of the editing operations such as writingand deleting carried out at times of accesses, even though its file nameitself remains unchanged. For this reason, there are cases in which itis necessary to store the file content of the file 113 at some selectedtimings, so as to be able to cope with a later request for reproducing astate of the file 113 at a desired one of the selected timings. Thistype of request is quite common in a case of the program development.

[0074] The most primitive scheme for realizing such a record management(version management) is to store the entire file content at eachselected timing. However, the difference (discrepancy) between differentversions is rather little in general, so that this primitive managementscheme is wasteful in terms of file sizes. Consequently, a scheme suchas the SCCS (Source Code Control System) and the RCS (Revision ControlSystem) which only stores an information on difference is usuallyemployed.

[0075] In the following, the outline of the data structure in eachrecord management scheme will be described.

[0076] First, a scheme that can be considered as a prototype of the RCSwill be explained. Here, this scheme will be referred as a differencepile up scheme. A file data structure in this difference pile up schemeis shown in FIG. 2. In this scheme, the file in the first version at atime of its creation is stored in its entirety, and set as the versionV.1 (block 201). Next, when a new version V.2 is created by deleting apart of the version V.1 or inserting something to the version V.1, adifference between the version V.2 and the version V.1 is obtained, andonly the obtained difference V.2−V.1 (block 202) is stored. Here, thedifference between versions is a set of data indicating facts such as“what is inserted where” and “from where to where is deleted” asprovided by the “diff” command of the UNIX for example. The changeencompassing the entire file is scarcely made, so that the size of thedifference is smaller than the size of the entire file in general. Thedata in such a stored state, i.e., the data for the version V.1 and thedata for the difference V.2−V.1, can provide sufficient information forrestoring the version V.2.

[0077] Subsequently, the difference between a new version after theediting and the latest stored version, such as the difference V.3−V.2(block 203) between the versions V.3 and V.2, the difference V.4−V.3(block 204) between the versions V.4 and V.3, etc. is obtained eachtime, and only the difference is additionally stored in a similarmanner.

[0078] Consequently, in this difference pile up scheme, in order torestore the latest version (current version), it is necessary to utilizethe records of all the versions complied up until then, but there is asignificant improvement in terms of file sizes.

[0079] Next, the RCS scheme will be explained. A file data structure forrecord management in this RCS scheme is shown in FIG. 3. In this RCSscheme, the records are managed as follows. First, the current version(block 304) is always stored in its entirety. In FIG. 3, a case in whichthe current version is version V.4 is shown. Then, the version V.3 whichis immediately previous to the version V.4 is stored in a format of thedifference V.3−V.4 (block 303) with respect to the version V.4. Thisscheme is characterized by taking the difference with reference to atimewise newer version in this manner. Thus, for the versions before theversion V.3, the difference V.2−V.3 (block 302) and the differenceV.1−V.2 (block 301) are stored similarly. In this state, in a case ofstoring a new version V.5, a processing for obtaining the differenceV.4−V.5 and a processing for storing the obtained difference and the newversion V.5 will be executed.

[0080] When this data structure is utilized, there is an advantage thatthe current version can be taken out easily. On the other hand, a caseof restoring the older version is going to require a longer time, butusually a newer version is going to be more frequently accessed, so thatthis scheme is in conformity with the general manner of usage.

[0081] Next, a scheme in which another representative record managementscheme known as the SCCS scheme is modified will be explained. This is aversion management scheme to memorize, in correspondence to each blockdata, an information indicating in which version that block data hasbeen inserted and an information indicating in which version that blockdata has been deleted.

[0082] An exemplary file data structure for record management in thismodified SCCS scheme is shown in FIG. 4. In the SCCS scheme, instead ofstoring the file data at a certain timing in its entirety, the file ismanaged in terms of blocks, and in a case of the insertion, a block ofan inserted size from an inserted position is created. Here, each blockis associated with two data fields 406 and 407, where a field 406indicates a creation timing or a version number at a timing of thecreation of each block (which serves as an example of information foridentifying a creation timing of each block), and a field 407 indicatesa deletion timing or a version number at a timing of the deletion ofeach block (which serves as an example of information for identifying adeletion timing of each block).

[0083] These two data fields 406 and 407 are just an example of a blockidentification information, which is an information to be attached inorder to facilitate the comprehension of a positioning of individualblock. Even in the difference pile up scheme or the RCS scheme describedabove, the block identification information has been given in a form ofa tag such as “difference V.X−V.Y” has been attached to the individualblock. In other words, the block identification information is aninformation indicating a relationship among blocks.

[0084] More specifically, as shown in FIG. 4, an exemplary file in thismodified SCCS record management scheme comprises four different versionsV.1 to V.4 for instance, and this file currently has five blocksincluding b1 (block 401), b2 (block 402), b3 (block 403), b4 (block404), and b5 (block 405).

[0085] Then, by referring to the contents of the two data fields 406 and407 described above, it is possible to see that this file has beenedited as follows.

[0086] First, in the version V.1 (first version), this file comprisedtwo blocks b2 and b3. Then, in the version V.2, blocks b2 and b4 wereadded at a top and a bottom of the file, respectively, so that this filein the version V.2 comprised four blocks b1, b2, b3, and b4. Next, inthe version V.3, a portion of the block b4 was changed and rewritten asthe block b5. In this case, the block b4 is attached with a flagindicating that it was deleted in the version V.3, and the recordmanagement to indicate that the block b5 was inserted is newly madeimmediately below the block b4. Consequently, this file in the versionV.3 comprised four blocks b1, b2, b3, and b5. Then, in the version V.4(current version), the block b2 was deleted so that the block b2 isattached with a flag indicating that it was deleted in the version V.4accordingly. Consequently, this file in the version V.4 comprises threeblocks b1, b3, and b5. Note that, before the version V.4, the blocks b2and b3 have been a single block, but in the version V.4, a first half ofthat block corresponding to the block b2 was deleted.

[0087] As can be seen in the above example, in the modified SCCS recordmanagement scheme, the file in the current version does not exist as acontinuous set, but any version can be taken out by connecting thoseblocks which had been created in that version or earlier versions andwhich had not been deleted by the time of that version, in an order fromtop to bottom, so that it is characterized by the fact that any versioncan be taken out without loading too much. Also, it can be seen thatthere is a tendency for blocks to be further divided as the versionprogresses. Thus, in this modified SCCS scheme, the record managementcan be realized easily as long as it is possible to specify the positionof the block to be inserted and a range to be deleted together.

[0088] Now, in the shared file editing system of this first embodiment,the cipher technique is utilized in order to provide a protection forthe reading of the file content. In this respect, the first feature ofthe present invention is characterized by that fact that it does notallow the server which is storing the file itself to read out filecontent, while the second feature of the present invention ischaracterized by the fact that it supports a plurality of subjects forcarrying out the editing operation with respect to the file by realizingthe asynchronous editing operation without using the exclusive actionssuch as locking as much as possible. Then, by combining the file datastructure as described above with this cipher feature, it becomespossible to realize the shared file editing system in which the secrecyof the file content with respect to the server can be secured while theasynchronous editing operation by a plurality of subjects can berealized by utilizing the above described file data structure.

[0089] In the following, the feature concerning the asynchronous editingwithout using the locking will be described. In realizing theasynchronous editing, the following problem must be resolved. Namely,suppose that a certain client A has read out the file in the currentversion V.4, and created a new version V.A by carrying out partialdeletion and insertion with respect to the read out version, whilealmost at the same time, another client B has also read out the file inthe current version V.4 at that timing and created a new version V.B bycarrying out partial deletion and insertion with respect to the read outversion. Then, assume that the write-back of the editing made by theclient A was executed before the write-back of the editing made by theclient B. In such a case, the version V.A is going to be stored as a newversion V.5 and the necessary record management is going to be carriedout, but then the write-back of the version V.B can give rise to acontradiction. That is, if the version V.B is stored as a still newerversion V.6, the latest version V.6 is not going to reflect the changesmade in the earlier version V.5. In order to prevent this problem, it isnecessary for each new version to be always capable of merging all thechanges that have been made up to then.

[0090] In order to realize this type of asynchronous editing, the sharedfile editing system of this first embodiment utilizes the recordmanagement as follows. Namely, the attention is paid to the fact thatevery editing action can be described as some combination of deletionand insertion, and this description can be determined uniquely as adifference with respect to the editing target version. With this fact inmind, one editing action El can be defined as a set Δ1 of editingprocedures for inserting what to where and deleting from where to wherewith respect to the version V.4, while another editing action E2 can bedefined similarly as a set Δ2 of other editing procedures with respectto the-same version V.4.

[0091] Then, when the write-back of the editing action E1 is to be madefirst, the new version V.5 is created by storing the editing proceduresΔ1 as a difference with respect to the editing target version V.4 in aformat suitable for the record management scheme. Then, when thewrite-back of the editing action E2 is to be made, the editingprocedures Δ2 which specify a difference with respect to the editingtarget version V.4 are converted into converted editing procedures Δ2′which specify a difference with respect to the latest version V.5, andthe new version V.6 is created by storing converted editing proceduresΔ2′ as a difference with respect to the previous version V.5 in a formatsuitable for the record management scheme. By repeating this operation,it is possible to realize the asynchronous editing without anycontradiction.

[0092] Here, what is important is to convert the editing procedureswhich are originally not defined as a difference with respect to thecurrent version into a difference with respect to the current versionwithout any contradiction. This mechanism can also be utilized tosupport an operation for carrying out the editing with respect to mucholder version, and merging the result of that editing with the currentversion.

[0093] Now, a configuration of an asynchronous editing system forrealizing the above described operation will be described with referenceto FIG. 5. In this FIG. 5, the asynchronous editing system comprises anediting unit 500, an editing procedure generation unit 501, an editingprocedure conversion unit 502, a record management informationgeneration unit 503, a record management unit 510, and a data memoryunit 511. Note that this asynchronous editing system is to bedistributed over the server 110 and the client 101 as described in thesecond embodiment, and a manner of distributedly arranging the elementsof this system is to be set according to whether or not to utilize theciphering of the file, although the editing unit 500 will be implementedon the client 101 and the data memory unit will be implemented on theserver 110 in any case.

[0094] The editing unit 500 carries out the editing with respect to thefile content in the editing target version obtained from the recordmanagement unit 510.

[0095] The editing procedure generation unit 501 receives the filecontent in the editing target version and the file content resultingfrom the editing carried out with respect to that file by the editingunit 500, and generates editing procedure data including insertion data,insertion positions, deletion start positions, and deletion endpositions, which indicate “what is inserted where” and “from where towhere is deleted”.

[0096] The editing procedure conversion unit 502 receives these editingprocedure data and record data described below, and generates theediting procedure data converted into the editing procedures withrespect to the current version. For example, for given editing proceduredata, the insertion data are left unchanged, while the insertionpositions are converted into corresponding positions with respect to thecurrent version, and the deletion start positions and the deletion endpositions are similarly converted into corresponding positions withrespect to the current version. In this conversion operation, the recorddata supplied from the record management unit 510 are utilized asnecessary supplementary input.

[0097] The record management unit 510 carries out the management of therecord data stored as an updating record of the editing target file. Theediting procedure data outputted from the editing procedure conversionunit 502 are entered into the record management information generationunit 503 and converted into the record data in a format suitable for therecord management scheme used by this record management informationgeneration unit 503, and these record data are sent to the recordmanagement unit 510, so as to carry out the updating of the latestversion.

[0098] The data memory unit 511 stores the file contents of a pluralityof files.

[0099] Next, the operation of each element in this asynchronous editingsystem shown in FIG. 5 will be described for specific record managementschemes. In any case, the editing procedure generation unit 501 carriesout the operation corresponding to the “diff” command of the UNIX.Namely, the editing procedure generation unit 501 compares the file datain the editing target version and the file data after the editing, andoutputs the editing procedure data such as “what is inserted where” and“from where to where is deleted”.

[0100] First, a case of using the difference pile up scheme of FIG. 2described above as the record management scheme will be described withreference to an exemplary situation depicted in FIG. 6.

[0101] In this example, the editing target version is the version V.2and the current version is the version V.4. Then, it is assumed that theoutput Δ1 of the editing procedure generation unit 501 is as follows.

[0102] i4

[0103] Newly inserted from here.

[0104] Can it be merged well?

[0105] d8, 9

[0106] This output indicates that, with respect to the version V.2, twolines (“Newly inserted from here.” and “Can it be merged well?”) areinserted at the line 4, and two lines from the line 8 to the line 9 aredeleted.

[0107] The editing procedure conversion unit 502 functions to convertthe above described editing procedure Δ1 into the editing procedure Δ1′with respect to the current version V.4. In this conversion, the recorddata from the record management unit 510 indicating the past records ofediting made from the version V.2 to the current version V.4 arenecessary.

[0108] As an example, suppose that the version V.3 deleted the line 2and the line 3 of the version V.2 and inserted one line (“This is line 5of V.2.”) at the line 5 of the version V.2, while the version V.4deleted the line 5 to the line 7 of the version V.3 and inserted twolines (“This part is changed this // way as I didn't like it.” where //indicates the line change) at the line 8 of the version V.3. In thiscase, for the insertion position in the editing procedure Δ1, it isnecessary to determine which line of the current version V.4 does theline 4 of the version V.2 corresponds to. To this end, the differencebetween versions V.3 and V.2 and the difference between versions V.4 andV.3 contain all the necessary information, and it can be recognized thatthe line 2 of the version V.4 corresponds to the line 4 of the versionV.2, so that “insert two lines at the line 4 of the version V.2” isconverted into “insert two lines at the line 2 of the version V.4”accordingly. Similarly, for the deletion, when the lines of the versionV.4 corresponding to the lines 8 and 9 of the version V.2 are checkedaccording to the record data, it can be recognized that the line 9 ofthe version V.2 corresponds to the line 7 of the version V.4 but theline 8 of the version V.2 had already been deleted in the version V.4.The deletion of a portion which had already been deleted normally doesnot make sense, so that “delete the line 8 to the line 9 of the versionV.2” is converted into “delete the line 7 of the version V.4” in thiscase. The editing procedure conversion unit 502 carries out theconversion of the editing procedures (mainly comprising the search ofthe changed positions) as described above. Thus, the record data areindispensable in this editing procedure conversion unit 502.

[0109] The record management information generation unit 503 obtains thedifference between the current version V.4 and the new version accordingto the editing procedure data Δ1′ so obtained and entered thereto. Here,as the difference pile up scheme is used as the record managementscheme, the above mentioned “insert two lines at the line 2 of theversion V.4” and “delete the line 7 of the version V.4” are turned intothe record data as they are, and these record data are sent to therecord management unit 510 and added to the stored record.

[0110] Next, a case of using the modified SCCS scheme of FIG. 4described above as the record management scheme will be described withreference to an exemplary situation depicted in FIG. 7. In this case,the operation for searching the changed positions at the editingprocedure conversion unit 502 can be simplified as follows.

[0111] Namely, suppose that the version V.2 had 10 lines as depicted inFIG. 7. Then, first, as the line 2 and the line 3 of the version V.2 aredeleted in the version V.3, the portion of these lines 2 and 3 becomesone block with the deletion time flag indicating “V.3”. Also, as oneline is inserted between the line 4 and the line 5 of the version V.2,the line 4 of the version V.2 becomes one block, while one line insertedin the version V.3 becomes another block with the creation time flagindicating “V.3”.

[0112] Next, as the line 5 to the line 7 of the version V.3 are deletedin the version V.4, the line 5 to the line 7 in the version V.3 bycounting only those lines which are not deleted at a time of the versionV.3 from top becomes one block with the deletion time flag indicating“V.4”. Also, as two lines are inserted between the line 7 and the line 8of the version V.3, these two inserted lines forms one block with thecreation time flag indicating “V.4”.

[0113] The editing procedure Δ1 outputted from the editing proceduregeneration unit 501 is similar to that described above, but the recorddata supplied from the record management unit 510 to the editingprocedure conversion unit 502 are given in a form of the version V.4 inFIG. 7. Then, at the editing procedure conversion unit 502, in order todetermine the line 4 (insertion position), the line 8 (deletion startposition), and the line 9 (deletion end position) at a time of theversion V.2, the fourth, eighth, and ninth lines from the top in theversion V.2 are figured out. Here, the point is to skip those portionswhich are inserted after the version V.2.

[0114] To the insertion position so determined, the two newly insertedlines (“Newly inserted from there. // Can it be merged well?”) areinserted as one block. In addition, as for the deletion, nothing is donefor the line 8 of the version V.2 as the deletion time flag is alreadyset up for it, while the line 9 is divided as one block with thedeletion time flag indicating “V.5”. The version V.5 produced in thismanner is then sent to the record management unit 510 so as to updatethe stored record data.

[0115] The record management information generation unit 503 accountsfor the operation up to the updating at the record management unit 510in the above described sequence.

[0116] As described, when a scheme such as the modified SCCS scheme isutilized as the record management scheme, the search of the changedpositions can be achieved by the simple counting from the top, so thatthe necessary operation can be simplified considerably.

[0117] Thus, in this first embodiment, it is possible to utilize thedata structure of FIG. 4 for the modified SCCS scheme as the recordmanagement scheme, while realizing the asynchronous editing according tothe configuration of FIG. 5 at the same time.

[0118] Now, another feature of this first embodiment concerning a cipherscheme for the file data will be described in detail.

[0119] The cipher scheme in this first embodiment is characterized bythe fact that the file is enciphered/deciphered in units of data blocksproduced in a course of the record management as described above, blockby block, and that the file structure which enables the server tocomprehend which data block corresponds to which portion of the file isadopted.

[0120] More specifically, as an example of such a file structure, in acase of using the difference pile up scheme of FIG. 2 as the recordmanagement scheme, each of the blocks 201, 202, 203, and 204 isenciphered independently and given in a form by which the server canrecognize the correspondence relationship such as “a block 201 is theenciphered data of the first version V.1”, “a block 202 is theenciphered data of the difference V.2−V.1 between the version V.2 andthe version V.1”, etc. As a concrete example, it is possible to providea flag field for the server management to each block to be enciphered,and enter an appropriate information such as V.1 or V.2−V.1 therein,

[0121] Such an information to be utilized by the server to identify eachdata block will be referred as the block identification information. Theflag field for the server management mentioned above, and the datafields 406 and 407 for the creation time and the deletion time in FIG. 4described above are examples of this block identification information.

[0122] As another example of the file structure, in a case of using theRCS scheme of FIG. 3 as the record management scheme, each of the blocks301, 302, 303, and 304 is enciphered independently, and given in a formby which the server can recognize the correspondence relationship suchas “a block 301 is the enciphered data of the difference V.1−V.2”, “ablock 302 is the enciphered data of the difference V.2−V.3”, etc.

[0123] As still another example of this file structure, in a case ofusing the modified SCCS scheme of FIG. 4 as the record managementscheme, each of the blocks 401, 402, 403, and 404 is encipheredindependently, and given in a form by which the server can recognize thecorrespondence relationship such as “a block 401 is a top block, a block402 is a next-to-top block”, etc. Here, it suffices to simply connectblocks such that the partitions among the block become apparent. Eachblock in FIG. 4 has two data fields 406 and 407 for the creation timeand deletion time in correspondence as mentioned above, but these datafields are not to be enciphered.

[0124] This manner of enciphering each block independently has anadvantage that the amount of processing required in the client and theamount of communication between the client and the server. Namely, whenthe client makes a request for the current version to the server in therecord management system of FIG. 3, it suffices for the server totransmit the enciphered block 304 alone. In contrast, if the entire datafile of FIG. 3 is enciphered together. it would be necessary for theserver to transmit the entire enciphered data, and in addition, it wouldalso be necessary for the client who received this transmitted data todecipher all the blocks 301 to 304 which are enciphered together, sothat many otherwise unnecessary processings would become necessary.

[0125] Also, in the record management scheme of FIG. 2, only change thatcan be made by the client side as a result of a new editing action is anaddition of an enciphered block for the difference V.5−V.4. In such acase, if the entire file is enciphered together, it would beparticularly difficult to verify that a portion near the partition withrespect to the difference V.4−V.3 has not been changed. Namely, theenciphering is usually made from a top of the file in a form of a chainof certain lengths dividing the file, so that it is, possible for theserver to conjecture the occurrence of an action to change a portionother than that near the end of the file from the cipher text, but sucha detection of a change cannot be made at a portion near the end of thefile (i.e., a portion near the newly added difference). In contrast,when the enciphering in units of blocks as described above is adoptedfor the data structure of FIG. 2, it suffices to sequentially add theenciphered data for a new difference, so that the server can easilycarry out the management to prevent the change of the records.

[0126] In view of realizing the asynchronous editing without lockingdescribed above, it is particularly suitable to use the recordmanagement scheme using the data structure of FIG. 4 even from a pointof view of the simplification of the merge processing. However, thistype of record management scheme has a characteristic that the blockwhich had been a single entity at one time is going to be subdividedsequentially at subsequent times. In general, in conjunction with thedivision of a block, there arises a need to re-encipher the block data,and for this reason, this first embodiment employs the cipher schemecapable of reducing the encipher/decipher processing, which will now beexplained in detail.

[0127] The data within each block can be considered as given by bits orbytes as minimum units, and in the first cipher scheme for this firstembodiment described below, in a case of dividing one block at severalpositions (point-1, point-2, and so on, in an order from the top of theblock), it is unnecessary to re-encipher the enciphered data from thetop of the block to the point-1 and the already enciphered data can beutilized as they are, so that only the data after the point-1 need to bere-enciphered.

[0128] Moreover, in the second cipher scheme for this first embodimentdescribed below, there is absolutely no need to re-encipher any data andthe already enciphered data can be utilized as they are.

[0129] In order to make such a re-utilization of the already enciphereddata possible, the cipher scheme is required to satisfy the followingcondition. Namely, in a case the cipher block is divided at an arbitrarypoint, it must be possible to obtain the corresponding plain text from afragment of that divided cipher block. Consequently, it is necessary tohave a particular bit (or byte) of the plain text to be incorrespondence to a particular bit (or byte) of the cipher text. As anatural consequence of that, there should not be a size increase due tothe enciphering. As a cipher scheme with such a property, a schemecalled stream cipher scheme is known, and a representative example ofthis scheme, there is a scheme for using the block cipher DES (DataEncryption Standard) in either the OFB (Output FeedBack) mode or the CFB(Cipher FeedBack) mode. The cipher procedure in the OFB mode is shown inFIG. 8, while the cipher procedure in the CFB mode is shown in FIG. 9.

[0130] First, with reference to FIG. 8, the operation principle in theOFB mode will be described. In this case, the transmitting side and thereceiving side share a key K for the block cipher devices 603 and 613and an initial value IV for shift registers 602 and 612 to be set ininitial value registers 601 and 611.

[0131] At a time of enciphering, the transmitting side enciphers acontent of the shift register 602 by the block cipher device 603, and Lbits of the obtained cipher result in the cipher result register 604 arefed back to the shift register 602 while also subjected to the exclusiveOR operation with respect to L bits of the plain text at the XOR circuit605. By repeating this processing, the plain text is enciphered in unitsof L bits. Here, even though an amount which is enciphered by oneprocessing is L bits, the enciphering is actually made bit by bit.

[0132] Similarly, at a time of deciphering, the receiving side deciphersa content of the shift register 612 by the block cipher device 613, andL bits of the obtained cipher result in the cipher result register 614are fed back to the shift register 612 while also subjected to theexclusive OR operation with respect to L bits of the cipher text at theXOR circuit 615. By repeating this processing, the cipher text isdeciphered in units of L bits. Again, even though an amount which isdeciphered by one processing is L bits, the deciphering is actually madebit by bit.

[0133] First, with reference to FIG. 9, the operation principle in theCFB mode will be described. In this case, the transmitting side and thereceiving side share a key K for the block cipher devices 623 and 633and an initial value IV for shift registers 622 and 632 to be set ininitial value registers 621 and 631.

[0134] At a time of enciphering, the transmitting side enciphers acontent of the shift register 622 by the block cipher device 623, and Lbits of the obtained cipher result in the cipher result register 624 aresubjected to the exclusive OR operation with respect to L bits of theplain text at the XOR circuit 625, while L bits of the cipher textobtained by the XOR circuit 625 are fed back to the shift register 622.

[0135] Similarly, at a time of deciphering, the receiving side deciphersa content of the shift register 632 by the block cipher device 633, andL bits of the obtained cipher result in the cipher result register 634are subjected to the exclusive OR operation with respect to L bits ofthe cipher text at the XOR circuit 635, while L bits of the receivedcipher text are fed back to the shift register 632.

[0136] Thus, this case of CFB mode differs from the above described caseof OFB mode only in that the data fed back to the shift register at atime of enciphering/deciphering are set to be the cipher text ratherthan the output of the block cipher device, in the transmitting side aswell as in the receiving side.

[0137] These modes are called L bit OFB mode or L bit CFB mode, using anumber of bits utilized in one encipher/decipher processing (whichcoincides with a number of bits to be fed back to the shift register),which are representative examples of the stream cipher in bit unit.Similarly, the representative examples of the stream cipher in byte unitinclude 8 bit OFB mode and 8 bit CFB mode. In these modes,. instead ofenciphering/deciphering by taking the exclusive OR of 8 bits of theplain text and 8 bits of the cipher device output bit by bit, it is alsopossible to modify them to use the enciphering/deciphering byaddition/subtraction of 8 bits, for example.

[0138] In the following, it is assumed that the minimum units of thedata within each block are bytes.

[0139] In order to guarantee the strength of the cipher text using thestream cipher as described above, when the key K is fixed, it ispreferable to change the initial value IV of the shift register for eachplain text. Otherwise, the cipher text has weak points in that theexclusive OR of two plain texts can be obtained by taking the exclusiveOR of the same position in two cipher texts, and that the two plaintexts can be recognized as the same when two corresponding cipher textshave the identical top portion. For this reason, in this firstembodiment, the initial value IV of the shift register is to be changedfor each block to be enciphered/deciphered.

[0140] Now, the cipher procedure at a time of the block data divisionusing the cipher scheme of this first embodiment will be described withreference to FIG. 10. In this FIG. 10, a left side of an arrow indicatesthe data structure before the block data division, and the right side ofan arrow indicates the data structure after the block data division.Here, FIG. 10 depicts an exemplary case in which a middle portion of acertain cipher block (block-0) is deleted, in which case this block isre-enciphered as three blocks for the top portion (block-1), the middleportion (block-2), and the bottom portion (block-3). For each block,there is provided a region 642 for storing the initial value data IV(IV0 to IV2). However, this initial value data IV is not to beenciphered.

[0141] In the first cipher scheme of this first embodiment, the L bitOFB mode or the L bit CFB mode is used, with L set to be a multiple of8. The initial value data IV of each block is generated by means of therandom number generation at a time of a new block creation. The blockdata are enciphered L bits by L bits in an order from the top asdescribed above. There is a case in which the end of the block does notcoincide with the L-th bit exactly, but even in such a case, the cipheris cut off at the length of the plain text. It is still possible todecipher the last portion even in such a case.

[0142] The cipher procedure at a time of the block data division asshown in FIG. 10 will be described with reference to the flow chart ofFIG. 11.

[0143] First, the top portion before the deletion start position isseparated as one block (block-l) as it is (step S1). Then, the initialvalue IV1 is determined by means of the random number generation (stepS2), and by the OFB (or CFB) mode using this initial value IV1, data ofthe deletion portion (plain text corresponding to block-2) areenciphered to form a new block (block-2) (step S3). Next, anotherinitial value IV2 is determined (step S4), and data of the bottomportion are enciphered to form a new block (block-3) (step S5).

[0144] This cipher procedure is characterized by the fact that the blockof the top portion utilizes the original initial value IV0 as it is, sothat there is no need to re-encipher this block.

[0145] Next, the second cipher scheme of this first embodiment which ischaracterized by the fact that there is absolutely no need tore-encipher any data will be described. In this case, the 8 bit CFB modeis used.

[0146] With respect to a new insertion block, the initial value data IVare generated by means of the random number generation, and the blockdata are enciphered byte by byte in an order from the top.

[0147] The cipher procedure at a time of the block data division asshown in FIG. 10 will be described with reference to the flow chart ofFIG. 12.

[0148] First, the cipher block (block-0) is divided into three atindividual division positions (step S11). Next, the last 8 bytes of theblock-1 are stored as the initial value data IV of the block-2 (stepS12). Then, the last 8 bytes of the block-2 are stored as the initialvalue data IV of the block-3 (step S13). At a time of storing theinitial value data IV at the steps S12 and S13, there can be a case inwhich the previous block is less than 8 bytes long. In such a case, itis necessary to employ a special treatment in which the previous blockis regarded as the initial value data IV+block data, such that the blockdata can be supplemented by as many bytes of the initial value data IVas necessary.

[0149] This second cipher scheme utilizes the property of the 8 bit CFBmode that the deciphering can be made from an arbitrary position, and ithas an advantage that the re-enciphering in conjunction with the blockdivision becomes totally unnecessary. This advantage also implies that,in a case of realizing the enciphered shared file system by the clientserver system, the server without the encipher/decipher function cancarry out the block division processing, so that the efficientrealization of the system becomes possible. It is also possible toexpand the above cipher procedure to the general L bit CFB mode (with Lset to be a multiple of 8), but the supplementary data become necessaryfor that purpose, because there can be a case in which the block-2 ofFIG. 10 does not start from the partition at L bits from the top of theoriginal block-0. The data of the block-2 are data enciphered in unitsof L bits from the top of the block-0, so that it is necessary to makeit possible to reproduce the original partitions in units of L bits. Tothis end, u bits (u is an integer for which u≦L) from the top of theblock is used as the supplementary data for indicating that it is afragmentary block, and at a time of deciphering, it is deciphered afterthe cipher text of (L-u) bits is added as a dummy at the top of theblock data and the top (L-u) bits in the deciphered result are ignored.The subsequent data can be deciphered in units of L bits. Also, theinitial value data IV to be stored at a time of the block division areset to be a content of 8 bytes immediately before the fragmentary bits(L-u bits) at the end of the previous block. In a case the previousblock is too short, just as in a similar case of the 8 bit CFB modeexplained above, the block data can be supplemented by the initial valuedata IV as much as necessary.

[0150] In the above, a case of the block division in conjunction withthe deletion has been described, but in a case of the insertion, itbecomes as follows. Namely, in a case of inserting a certain block in amiddle of already existing block, there is a need for a division of thealready existing block corresponding to the procedure of FIG. 11 or FIG.12 described above, as well as for the enciphering of a new insertionblock data. Here, the enciphering of a new insertion portion is made bydetermining the initial value IV by means of the random numbergeneration, and then by using the OFB (or CFB) mode using this initialvalue IV. Also, in a case of inserting a certain block between alreadyexisting blocks, no change is necessary for the already existing blocks,and it suffices to encipher the new insertion block alone.

[0151] In the following the features of the record management schemeaccording to this first embodiment will be summarized. Here, the sharedfile editing system using the enciphered difference pile up scheme shownin FIG. 2, the shared file editing system using the enciphered RCSscheme shown in FIG. 3, and the shared file editing system using theenciphered SCCS scheme shown in FIG. 4 will be compared.

[0152] First, regarding the asynchronous editing function withoutlocking, the enciphered SCCS scheme is advantageous because the mergeprocessing can be simplified as already explained above.

[0153] Next, regarding the take out of the current version, theenciphered RCS scheme is most advantageous as it stores the currentversion as it is in a form of the enciphered data. The enciphered SCCSscheme is advantageous next, and it has a characteristic that anarbitrary version can be restored by the same level of processing.

[0154] Next, in view of a case in which it is desired to delete the oldrecords in order to compress the file size, the enciphered RCS schemeand the enciphered SCCS scheme are both superior. This is because, inthese schemes, the server which received a request to this end candelete the records by itself. In the enciphered difference pile upscheme, the old records can be deleted by an interaction from theclient.

[0155] Here, it should be noted that, in a case of the enciphered SCCSscheme, the fusion of the blocks does not takes place even when the oldrecords are deleted, and only the separation of the unnecessary blocksis carried out. In a case of carrying out the fusion of the blocks aswell, the interaction from the client becomes necessary. Also, it shouldbe noted that, in the enciphered RCS scheme, what the server can do byitself is to delete the records in an order from the older side.

[0156] It is preferable to manage the record content to be not changedlater on, and regarding such a completeness of the record content, theenciphered difference pile up scheme is superior. As explained earlier,the client is only allowed to sequentially add differences in thisscheme, so that the completeness of the records can be guaranteed.

[0157] As described above, by applying one or both of the characteristicfeatures of this first embodiment, it becomes possible to provide ashared file editing system which supports the file version management,which is capable of realizing the asynchronous editing while keeping thefile contents secret from the file server, or a shared file editingsystem which supports the file version management, which is capable ofrealizing the asynchronous editing, or a file editing system capable ofrealizing a higher level of secrecy such that the file contents cannotbe read out from the file server.

[0158] In the above, in enciphering the structured files, the datacontent is enciphered such that only the client can encipher/decipherit, but the data structure in a format that can also be recognized bythe server has been shown, and in particular, the applications to theversion management and the asynchronous editing have been described. Thepresent invention is applicable to various other systems and schemes,such as a scheme for enciphering the program in units of sub-routines,and a scheme for dealing with a plurality of data files which are linkedtogether as in the hypertext, in which the data files are enciphered inunits of data files and linked portions are not enciphered. In thismanner, it becomes possible to realize an efficient manner ofutilization in which the client can read out only the necessary portionwhile maintaining the secrecy of the module content with respect to theserver.

[0159] Next, the second embodiment of a shared file editing systemaccording to the present invention, in which the above described firstfeature concerning the file content secrecy with respect to the serverand the above described second feature concerning the asynchronousediting are implemented on the client server type system will bedescribed in detail.

[0160] In this second embodiment, the individual features related to thefile structure, the record management scheme, the cipher scheme, and theasynchronous editing system are basically the same as those for thefirst embodiment described above, and their detailed descriptions willnot be repeated here. In the following, the configuration and theoperation characteristic to this second embodiment will be described.

[0161]FIG. 13 shows a first configuration of the shared file editingsystem of this second embodiment, which generally comprises a pluralityof clients 91 and a server 90.

[0162] The server 90 further comprises a communication (COMM) unit 131for carrying out a communication with each client 91 through acommunication path 111, a record management unit (for shared file) 510for managing records for shared files, and a data memory unit 511 forstoring a plurality of files, where the record management unit 510 andthe data memory unit 511 correspond to the record management unit 510and the the data memory unit 511 in the asynchronous editing system ofFIG. 5 described above.

[0163] On the other hand, each client 91 further comprises acommunication (COMM) unit 130 for carrying out a communication with theserver 90 through the communication path 111, a memory 121 for storingfiles obtained from the server 90, a shared file editing unit 122 forediting the shared files, and a cipher unit 112 forenciphering/deciphering the files.

[0164] As shown in FIG. 14, the shared file editing unit 122 includesthe editing unit 500, the editing procedure generation unit 501, theediting procedure conversion unit 502, and the record managementinformation generation unit 503 corresponding to those in theasynchronous editing system of FIG. 5 described above.

[0165] As shown in FIG. 15, the cipher unit 112 includes a communication(COMM) unit 132 connected with the shared file editing unit 122, anencipher/decipher processing unit 1121 connected with the communicationunit 132, and a key memory unit 1122 connected with theencipher/decipher processing unit 1121.

[0166] Now, as a plurality of clients 91 are provided in this secondembodiment, requests for the following three types of operations occurat various timings:

[0167] (a) a reading of file data of a particular version (arrow from510 to 500 in FIG. 5);

[0168] (b) a writing of a record management information which is anediting result (arrow from 503 to 510 in FIG. 5); and

[0169] (c) a reading of record data necessary in converting the editingprocedure (arrow from 510 to 502 in FIG. 5).

[0170] Here, a general procedure for dealing with these requests in thissecond embodiment will be described.

[0171] As described before, the editing procedure corresponding to onerecord management information comprises a combination of a plurality ofinsertions and deletions, and it is preferable to handle them together.That is, when a certain client 91 made changes at a plurality ofpositions in the file of a certain version, a new version is made at atiming at which all these changes are reflected in the data on theserver 90 side. The write requests for the record management informationare set in a queue one by one, and sequentially reflected into the filedata as they are sequentially taken out by the record management unit510 in First-in-First-out manner. Here, the record management unit 510responds to the read requests ((a) and (c) mentioned above) from theclient 91 whenever necessary, but in a case the read request for thecurrent version of one file arrives during the updating of the file datafor the same file at the record management unit 510, there is a need totransmit the version before the updating.

[0172] The client 91 requests the data of a certain version (version X)from the server 90 initially, and after storing the data in the memory121, the editing is carried out at the editing unit 500, and the editingprocedure data are generated at the editing procedure generation unit501. In a case the version X is the latest version at a time of reading,the editing procedure is not converted and the record managementinformation is generated immediately, and subsequently enciphered andtransmitted to the server 90. At the receiving server 90 side, whetherit is the record management information that can be merged with thelatest version at that timing or not is judged, and if it cannot bemerged, the record data are transmitted from the record management unit510 to the client 91, to request the conversion of the editing procedureat the editing procedure conversion unit 502.

[0173] Here, the judgment as to whether it can be merged or not can bemade by attaching a version number of the target data to a header of therecord management information to be transmitted at the client 91 side,such that the server 90 side can compare the version number in theheader with the version number of the latest version stored therein, andjudge that it can be merged when they coincide, and that it cannot bemerged otherwise. In addition, the record data to be transmitted to theclient 91 when it cannot be merged can be the record data between thelatest version and the version indicated by the version number in theheader of the record management information for example. At the client91 side, the prescribed editing procedure conversion is carried out togenerate a new record management information, and this is sent to theserver 90 again, such that the server 90 side judges whether it can bemerged or not again.

[0174] Here, there is a possibility that the new record managementinformation cannot be merged again. Namely, it is a case where the fileversion has been updated by the other client during the editingprocedure conversion processing at this client 91. Consequently, thereis a possibility for circulating through the loop of 510→502→503 in FIG.5 many times.

[0175] In order to prevent such a repetitive processing, it is possibleto utilize the lock function. Namely, at a timing at which the recorddata are transmitted to the client 91, the server 90 side sets the lockon the updating of the file data, and releases the lock at a timing atwhich the updating of the file data is completed after the recordmanagement information is received from that client 91. While the lockis set, the reading of the editing target file data is permitted, butthe other processing is rejected at the server 90 side. The other client91 whose request has been rejected will make a re-try after anappropriate amount of time. Here, the waiting period due to this lockmechanism can be considered as very short, but this lock mechanism isnot absolutely necessary.

[0176] On the other hand, in a case the version X initially read outfrom the server 90 is not the latest version at a time of reading, forthe purpose of the processing at the editing procedure conversion unit502, the record data from that version X to the latest version arerequested to the server 90. Thereafter, the operation similar to thatalready described above is carried out.

[0177] In the above procedure, the editing target file and the recorddata received by the client 91 and the record management informationtransmitted to the server 90 are all enciphered in units of structuralunits, and they are enciphered/deciphered by means of the cipher unit112.

[0178] In this manner, in this second embodiment, the file content canbe read out from the proper client who has the decipher key, and thefile content cannot be read out from the server, so that the fileediting system with a high secrecy for the file content can be realized.

[0179] Also, at the server, the updating with respect to the filecontent of the latest version is made always at a timing of thecompletion of the editing by each client, so that it becomes possible torealize the asynchronous editing by a plurality of clients, withoututilizing the lock mechanism.

[0180] Also, it becomes possible to realize a manner of usage in whichthe version which is already old in time is edited, and the latestversion is made out of it. Namely, for the shared file that can beasynchronously edited, it becomes possible to realize a manner of usagein which the editing target is not necessarily limited to the currentversion alone.

[0181] Also, in a case of executing the merge processing of the editingresults obtained by the asynchronous editing, it is possible to realizea scheme in which only data necessary for the processing at the clientside alone are transmitted from the server, and the merged result isreturned to the server after the necessary processing is executed at theclient side, so that the wasteful communication of portions related tounnecessary records can be eliminated, and consequently the systemefficiency can be improved considerably.

[0182] As for the file data structure, by using the structure used inthe SCCS scheme in which the data sequentially inserted from a top ofthe file are managed at inserted positions as blocks, and the blocks aresequentially divided in a case of the partial deletions, rather than thestructure used in the RCS scheme in which the difference with respect tothe immediately previous (or subsequent) version is simply left, thedetermination of the insertion/deletion positions required in the mergeprocessing can be simplified considerably, so that the asynchronousediting becomes easier.

[0183] Also, as the cipher scheme for the data content in a case ofusing the data structure of the SCCS scheme suitable for the mergeprocessing, the stream cipher in bit unit (or byte unit) can beutilized. This stream cipher has a property that a particular bit (orbyte) of the plain text corresponds to a particular bit (or byte) of thecipher text. For this reason, when the enciphered blocks as sequentiallydivided, it suffices to separate the portion after the dividing pointand re-encipher that separated portion alone, so that the overhead dueto the re-enciphering can be reduced. In addition, it is also possiblefor the server side to confirm that the portion before the dividingpoint has not been changed.

[0184] As mentioned above, the shared file editing system of this secondembodiment involves a loop of 510→502→503 in FIG. 5. In the following,the second configuration for this second embodiment which resolves thisloop will be described.

[0185] In this second configuration, the file data structure of themodified SCCS scheme shown in FIG. 4 is used, and the cipher scheme ofthe 8 bit CFB mode among the stream cipher is used. This cipher schemehas a characteristic that the re-enciphering is totally unnecessary evenat a time of dividing the blocks as already explained above.

[0186]FIG. 16 shows this second configuration of the shared file editingsystem of this second embodiment, which generally comprises a pluralityof clients 211 and a server 210.

[0187] The server 210 further comprises a communication (COMM) unit 231for carrying out a communication with each client 91 through acommunication path 111, an editing procedure conversion unit 502 forconverting the editing procedure, a record management unit (for sharedfile) 510 for managing records for shared files, and a data memory unit511 for storing a plurality of files, where the editing procedureconversion unit 502, the record management unit 510, and the data memoryunit 511 correspond to the editing procedure conversion unit 502, therecord management unit 510, and the the data memory unit 511 in theasynchronous editing system of FIG. 5 described above. Here, the editingprocedure conversion unit 502 also functions as the record managementinformation generation unit 503 of FIG. 5 as well.

[0188] On the other hand, each client 211 further comprises acommunication (COMM) unit 230 for carrying out a communication with theserver 210 through the communication path 111, a memory 221 for storingfiles obtained from the server 210, a shared file editing unit 222 forediting the shared files, and a cipher unit 212 forenciphering/deciphering the files.

[0189] As shown in FIG. 17, the shared file editing unit 222 includesthe editing unit 500 and the editing procedure generation unit 501,which are corresponding to those in the asynchronous editing system ofFIG. 5 described above.

[0190] Now, as a plurality of clients 211 are provided in this secondembodiment, requests for the following two types of operations occur atvarious timings:

[0191] (a) a reading of file data of a particular version (arrow from510 to 500 in FIG. 5); and

[0192] (b) a writing of editing procedure data obtained by converting anediting result (arrow from 501 to 502 in FIG. 5).

[0193] Here, an exemplary procedure for dealing with these requests inthis second embodiment will be described.

[0194] The client 211 initially requests the data of a certain versionfrom the server 210. Then, after the data of that version are decipheredand stored in the memory 221, the editing is carried out at the editingunit 500, and the editing procedure data are generated at the editingprocedure generation unit 501. Here, the editing procedure data includestwo data types of insertion data and deletion data. The insertion datacomprises a set of an insertion position (a number of bytes from a topposition for example) and an insertion block content, while the deletiondata comprises a set of a deletion start position and a deletion endposition.

[0195] For the insertion block content, the client 211 generates theinitial value IV and enciphers the block by the 8 bit CFB mode. Theother data (such as the insertion position and the deletion range) arenot enciphered, and transmitted together with the enciphered insertionblock content to the server 210.

[0196] At the server 210 which received this, the insertion position andthe deletion range are converted (position conversion) into the positiondata with respect to the latest version at that timing by the editingprocedure conversion unit 502. Then, the enciphered insertion blocktransmitted from the client is arranged at the converted insertionposition, while the block division and the deletion time field entry aremade for the converted deletion range by the record management unit 510.The result obtained so far is then set as the latest version.

[0197] In the above procedure, the important point is that theconversion of the editing procedure can be made in am enciphered state,and for this reason, the above described loop for the purpose of theediting procedure conversion in the above described general procedurecan be resolved. As the file data structure and the cipher scheme forenabling the editing procedure conversion in the enciphered state, acombination of the modified SCCS scheme and the 8 bit CFB mode is used.The similar effect can also be obtained by using the other cipher schemesuch as the L bit OFB mode or the L bit CFB mode for which there-enciphering is unnecessary for the first block in a case of the blockdivision, but extra data will be required as the editing procedure datato be transmitted from the client to the server in such a case, comparedwith a case described above.

[0198] In this manner, in this second embodiment, the file content canbe read out from the proper client who has the decipher key, and thefile content cannot be read out from the server, so that the fileediting system with a high secrecy for the file content can be realized.

[0199] Also, at the server, the updating with respect to the filecontent of the latest version is made always at a timing of thecompletion of the editing by each client, so that it becomes possible torealize the asynchronous editing by a plurality of clients, withoututilizing the lock mechanism.

[0200] Thus, in this second embodiment, the arrangement of the mainfeatures in the first configuration of FIG. 13 and the secondconfiguration of FIG. 16 described above can be summarized as shown inFIG. 18 and FIG. 19, respectively.

[0201] In the configuration of FIG. 18, the block identificationinformation may be attached to the record management information to betransmitted from the client 91 to the server 90 by an operation of therecord management information generation unit 503 on the client 91 side.In such a case, the block identification information is not encipheredwhile the entire record management information are enciphered by thecipher unit 112, so that the server 90 can manage the new data blockindicated by the record management information according to the attachedblock identification information which is not enciphered and thereforerecognizable on the server 90 side, even though the data content of theenciphered record management information is not recognizable to theserver 90. Alternatively, the block identification information may notbe attached to the record management information to be transmitted fromthe client 91 to the server 90, in which case the appropriate blockidentification information for identifying the new block data indicatedby the record management information can be attached at the recordmanagement unit 510 on the server 90 side.

[0202] In the configuration of FIG. 19. only the editing procedure dataare transmitted from the client 211 to the server 210, and the blockidentification information for identifying the new block data resultingfrom this editing procedure data is attached by the operation of therecord management information generation unit 503 or the recordmanagement unit 510 on the server 210 side. Here, only the insertiondata contents are enciphered by the cipher unit 212, while the otherparts of the editing procedure data are not enciphered, such that theediting procedure conversion unit 502 on the server 210 side can carryout the conversion of the editing procedure data according to theseother parts of the editing procedure data which are not enciphered andtherefore recognizable on the server 210 side, along with the recorddata provided from the record management unit 510.

[0203] It is also possible to modify this configuration of FIG. 19 toprovide the editing procedure conversion unit 502 on the client 211side, between the editing procedure generation unit 501 and the cipherunit 212, to realize a hybrid of the configurations of FIGS. 18 and 19.In such a case, only the converted editing procedure data aretransmitted from the client 211 to the server 210, and the blockidentification information for identifying the new block data resultingfrom this converted editing procedure data is attached by the operationof the record management information generation unit 503 or the recordmanagement unit 510 on the server 210 side. In this case, only theconverted insertion data contents are enciphered by the cipher unit 212,while the other parts of the editing procedure data are not enciphered,such that the record management information generation unit 5023 on theserver 210 side can carry out the generation of the record managementinformation according to these other parts of the converted editingprocedure data which are not enciphered and therefore recognizable onthe server 210 side.

[0204] Now, the above described first feature concerning the filecontent secrecy with respect to the server and the above describedsecond feature concerning the asynchronous editing are separatelyrealizable. In the following, the embodiments of a shared file editingsystem implementing one of these features separately will be describedin detail.

[0205] First, the third embodiment of a shared file editing systemaccording to the present invention, in which the above described secondfeature concerning the asynchronous editing is implemented on the clientserver type system will be described in detail.

[0206] In this third embodiment, the individual features related to thefile structure, the record management scheme, and the asynchronousediting system are basically the same as those for the first embodimentdescribed above, and their detailed descriptions will not be repeatedhere. In the following, the configuration and the operationcharacteristic to this third embodiment will be described.

[0207]FIG. 20 shows a configuration of the shared file editing system ofthis third embodiment, which generally comprises a plurality of clients701 and a server 710.

[0208] The server 710 further comprises a communication (COMM) unit 731for carrying out a communication with each client 701 through acommunication path 111, a merge processing unit 740 for carrying out themerge processing, and a data memory unit 511 for storing a plurality offiles, where the data memory unit 511 corresponds to the the data memoryunit 511 in the asynchronous editing system of FIG. 5 described above.

[0209] On the other hand, each client 701 further comprises acommunication (COMM) unit 730 for carrying out a communication with theserver 710 through the communication path 111, a memory 721 for storingfiles obtained from the server 710, and a shared file editing unit 722for editing the shared files.

[0210] As shown in FIG. 21, the shared file editing unit 722 of theclient 701 includes the editing unit 500 and the editing proceduregeneration unit 501, which are corresponding to those in theasynchronous editing system of FIG. 5 described above.

[0211] As shown in FIG. 22, the merge processing unit 740 of the server710 includes the editing procedure conversion unit 502, the recordmanagement information generation unit 503, and the record managementunit 510, which are corresponding to those in the asynchronous editingsystem of FIG. 5 described above.

[0212] Now, as a plurality of clients 701 are provided in this thirdembodiment, requests for the following two types of operations occur atvarious timings:

[0213] (a) a reading of file data of a particular version (arrow from510 to 500 in FIG. 5); and

[0214] (b) a writing of editing procedure data obtained by converting anediting result (arrow from 501 to 502 in FIG. 5).

[0215] Here, an exemplary procedure for dealing with these requests inthis second embodiment will be described.

[0216] In this case, the client 701 requests the file data of aparticular version from the server 710, and after that file is stored inthe memory 721, the editing is carried out at the editing unit 500, theediting procedure data are generated at the editing procedure generationunit 501, and the obtained editing procedure data are transmitted to theserver 710.

[0217] At the server 710, the editing procedure data are entered intothe queue one by one, and the merge processing unit 740 sequentiallytakes out the editing procedure data in the queue, converts them intothe records and store them. Unlike a case of the system with cipherfunction described above, this third embodiment is characterized in thatthe server 710 by itself can carry out the editing procedure conversionwith respect to the latest version. Namely, the client 701 carries outthe editing procedure conversion according to the editing procedure dataand the record data, and then store the result as the record.Consequently, the above mentioned loop of 510→502→503 in FIG. 5 isabsent in this third embodiment, and therefore there is no need for thelock mechanism for the purpose of preventing the repetitive processingthrough the loop. In addition, the function of the shared file editingunit 722 provided on the client 701 side can also be reduced.

[0218] Here, just as in a case of the embodiment incorporating the firstfeature concerning the file content secrecy with respect to the server,it is also possible to use a configuration in which the editingprocedure conversion unit 502 and the record management informationgeneration unit 503 are provided on the client 701 side. In such a case,the operation of each element is substantially similar as describedabove for the second embodiment. It is also possible to move the editingprocedure generation unit 501 from the shared file editing unit 722provided on the client 701 to the server 710 side.

[0219] Thus, in this third embodiment, at the server, the updating withrespect to the file content of the latest version is made always at atiming of the completion of the editing by each client, so that itbecomes possible to realize the asynchronous editing by a plurality ofclients, without utilizing the lock mechanism.

[0220] Also, it becomes possible to realize a manner of usage in whichthe version which is already old in time is edited, and the latestversion is made out of it. Namely, for the shared file that can beasynchronously edited, it becomes possible to realize a manner of usagein which the editing target is not necessarily limited to the currentversion alone.

[0221] Also, in a case of executing the merge processing of the editingresults obtained by the asynchronous editing, it is possible to realizea scheme in which only data necessary for the merging at the client sidealone are transmitted from the server, and the merged result is returnedto the server after the necessary processing is executed at the clientside, so that the wasteful communication of portions related tounnecessary records can be eliminated, and consequently the systemefficiency can be improved considerably.

[0222] As for the file data structure, by using the structure used inthe SCCS scheme in which the data sequentially inserted from a top ofthe file are managed at inserted positions as blocks, and the blocks aresequentially divided in a case of the partial deletions, rather than thestructure used in the RCS scheme in which the difference with respect tothe immediately previous (or subsequent) version is simply left, thedetermination of the insertion/deletion positions required in the mergeprocessing can be simplified considerably, so that the asynchronousediting becomes easier.

[0223] Next, the fourth embodiment of a file editing system according tothe present invention, in which the above described first featureconcerning the file content secrecy with respect to the server isimplemented on the client server type system will be described indetail.

[0224] The file handled in this fourth embodiment includes a pluralityof block data and block identification information, and each block dataare enciphered in units of block data. The file data has the datastructure such as that of FIG. 2, FIG. 3, or FIG. 4 described above, forexample, but besides these, this fourth embodiment is also applicable tovarious other systems and schemes, such as a scheme for enciphering theprogram in units of sub-routines, and a scheme for dealing with aplurality of data files which are linked together as in the hypertext,in which the data files are enciphered in units of data files and linkedportions are not enciphered. In this manner, it becomes possible torealize an efficient manner of utilization in which the client can readout only the necessary portion while maintaining the secrecy of themodule content with respect to the server.

[0225] Also, in this fourth embodiment, with respect to the files withthe data structure as described above, the cipher scheme described abovefor the first embodiment is used.

[0226]FIG. 23 shows a configuration of the file editing system of thisfourth embodiment, which generally comprises a plurality of clients 801and a server 810.

[0227] The server 810 further comprises a communication (COMM) unit 831for carrying out a communication with each client 801 through acommunication path 111, a data management unit 840 for managing the filedata, and a data memory unit 511 for storing a plurality of files.

[0228] On the other hand, each client 801 further comprises acommunication (COMM) unit 830 for carrying out a communication with theserver 810 through the communication path 111, a memory 821 for storingfiles obtained from the server 810, a file editing unit 822 for editingthe files, and a cipher unit 812 for enciphering/deciphering the files.

[0229] As shown in FIG. 24, the cipher unit 812 includes a communication(COMM) unit 832 connected with the file editing unit 822, anencipher/decipher processing unit 8121 connected with the communicationunit 832, and a key memory unit 8122 connected with theencipher/decipher processing unit 8121.

[0230] In this configuration, the client 801 requests the file data of aparticular version from the server 810, and after that file is stored inthe memory 821, the editing is carried out at the file editing unit 822.At this point, the file is enciphered in units of block data as alreadymentioned above, so that the file is deciphered by using the decipherkey registered in the key memory unit 8122 at the encipher/decipherprocessing unit 8121, After the editing of the file is finished, thefile is enciphered by using the cipher key registered in the key memoryunit 8122 at the encipher/decipher processing unit 8121, and transmittedto the server 810, such that the file in the data memory unit 511 isupdated by the data management unit 840 at the server 810.

[0231] In this manner, in this fourth embodiment, it is possible torealize the file editing system with a high secrecy for the file contentin which the file content cannot be read out from the server.

[0232] Also, the client can obtain only the necessary data block amongthe files through the communication, so that it is possible to reducethe amount of communication, and also it suffices to decipher/encipherthe necessary blocks alone, so that it is possible to reduce the amountof processing at the client side, and consequently the buffer (memory)required for the client can also be reduced.

[0233] Now, in this fourth embodiment, it is also possible to apply therecord management scheme as described above for the first embodiment, asfollows.

[0234] In this case, the file data structure of FIG. 2, FIG. 3, or FIG.4 described above is used. Also, with respect to the files with such adata structure, the cipher scheme described above for the firstembodiment is used.

[0235] Here, the asynchronous editing is not carried out, so that it ispossible to use the record management system in which the editingprocedure conversion unit 502 in the asynchronous editing system of FIG.5 is omitted and the editing procedure generation unit 501 and therecord management information generation unit 503 can be connecteddirectly, and the record management unit 510 is set as the datamanagement unit 840 which is modified to have a function to manage thedata memory unit 511 alone. This record management system isdistributedly arranged in the file editing unit 822 and the datamanagement unit 840.

[0236] Here, as long as the editing unit 500 is implemented on the fileediting unit 822 of the client 801, and the data management unit 840 andthe data memory unit 511 are implemented on the server 810, the otherelements may be distributedly arranged in any desired form.

[0237] Here, as a preferable form, the data management unit 840 and thedata memory unit 511 alone are implemented on the server 810 while allthe other elements are implemented on the client 801, as in FIG. 23,will be described.

[0238] In this configuration, the client 801 requests the file data of aparticular version from the server 810, and after that file is stored inthe memory 821, the editing is carried out at the file editing unit 500.At this point, the file is enciphered in units of block data as alreadymentioned above, so that the file is deciphered by using the decipherkey registered in the key memory unit 8122 at the encipher/decipherprocessing unit 8121. After the editing of the file is finished, theediting procedure data are generated at the editing procedure generationunit 501. Then, the obtained editing procedure data are converted intothe record data in a format suitable for the record management schemeused at the record management information generation unit 503. Then, therecord data are enciphered by using the cipher key registered in the keymemory unit 8122 at the encipher/decipher processing unit 8121, andtransmitted to the server 810, such that the file in the data memoryunit 511 is updated by the data management unit 840 at the server 810.

[0239] In this manner, the file version management and the file datasecrecy with respect to the file management server can be realizedsimultaneously.

[0240] Also, in a case the file data structure of the difference pile upscheme shown in FIG. 2 is used, the completeness of the record can beguaranteed by the file management server side alone.

[0241] Also, in a case the file data structure of the RCS scheme shownin FIG. 3 is used, the reading of the file in the current version andthe deletion of old records can be made easier in the file versionmanagement.

[0242] Also, in a case the file data structure of the modified SCCSscheme shown in FIG. 4 is used, the deletion of old records in the fileversion management can be made easier.

[0243] Also, in a case of using the stream cipher as the cipher scheme,in the enciphering at a time of block division, a portion from a top ofthe block to the division point can be re-utilized in the encipheredstate, and it suffices to re-encipher only a portion after the divisionpoint. It is also possible to use the cipher scheme in which absolutelyno re-enciphering is necessary. This cipher scheme is advantageous in acase of sequentially dividing blocks as in the SCCS scheme.

[0244] Next, the fifth embodiment of a shared file editing systemaccording to the present invention will be described in detail. In thisfifth embodiment, the shared file editing system of FIG. 13, FIG. 16, orFIG. 20 described above is further equipped with an additional functionfor delaying an execution of a deletion of a version in response to adeletion request for a certain version of a certain file, until noclient remains to be editing that certain version of that certain file.

[0245] In the system employing the record management, it is possible toprovide a function for deleting some versions among the records. Such adeletion of a version may be made when the client executes a deletioncommand for example, or in a case the system automatically deletes anyversion for which more than a prescribed period of time has elapsedsince its creation.

[0246] In the shared file editing system with the asynchronous editingfunction according to the present invention, at a time of deleting aversion, there should not be any client who is editing that deletiontarget version. This is because the file management server carries outthe merge processing for converting the version accessed by the clientinto the latest version in the file management server in such a system,and if a version is deleted while that version is edited by some clientin such a system, the merge processing for the editing made by thatclient would become impossible.

[0247] In this fifth embodiment, in order to realize the versiondeletion function, the file management server is provided with means forcounting a number of clients who are editing each version of each file,in correspondence to each version of each file managed by the filemanagement server. By this means, the file management server can Judgewhether there exists any client who is editing each version of eachfile. Namely, when the count value for a specified version of aspecified file is 0, it implies that there is no client who is editingthat version of that file, whereas when that count value is not equal to0, it implies that there exists a client who is editing that version ofthat file.

[0248] Then, the file management server of this fifth embodiment isfurther provided with means for delaying the execution of the deletionof a version when the deletion of a certain version of a certain file isrequested and the count value for that version of that file is not equalto 0, until that count value becomes 0. By this means, the filemanagement server is not going to delete that version of that file whilethere exists a client who is editing that version of that file which isthe deletion target, so that the merge processing for the editing madeby that client can be carried out without a trouble.

[0249]FIG. 25 shows a configuration of the shared file editing system ofthis fifth embodiment as outlined above, which is based on the sharedfile editing system of FIG. 13 described above.

[0250] In this configuration of FIG. 25, each access requesting client91 and the communication path 111 are substantially similar as those inFIG. 13. The file management server 95 differs from that of FIG. 13 inthat it further includes a client counting unit 900.

[0251] As shown in FIG. 26, this client counting unit 900 comprises abranching unit 901, an editing start processing unit 902, a deletionrequest processing unit 903, and an editing end processing unit 904, acount memory unit 905, and a deletion command issuing unit 906.

[0252] The basic functions of this client counting unit 900 include thecounting how many clients are editing each version of each file incorrespondence to each version of each file managed by the filemanagement server 95, and the delaying of the execution of a deletion ofa version when the deletion of a certain version of a certain file isrequested from a certain client but the count value for that version ofthat file counted by the client counting means 900 is not equal to 0,until that count value becomes 0.

[0253] Here, the basic role of the count memory unit 905 in the clientcounting unit 900 is that, for each version of each file, it stores thecount value (an integer) and a deletion delay flag (1 bit indicatingtruth or false) in correspondence. The count value is a counter forcounting how many clients are editing that version of that file, whilethe deletion delay flag is a flag for indicating that the execution ofthe deletion is delayed because the count value is not equal to 0.

[0254] An exemplary data structure of the data stored in the countmemory unit 905 is shown in FIG. 27, which is in a form of array in twosteps. The array of the first step makes a correspondence between thefile ID and the arrays of the second step, which is an array of entrieswith each entry containing a pair of the file ID and a count arrayaddress. Each array of the second step stores the count value and thedeletion delay flag for different versions of each file, which is anarray of entries with each entry containing a pair of the count valueand the deletion delay flag. In this array of the second step, theversion number is referred as an index in the array. Thus, for example,C11, C12, and C13 shown in FIG. 27 are the count values for the versionswith version numbers 1, 2, and 3 of the file with the file ID1, whileF11, F12, and F13 shown in FIG. 27 are the deletion delay flags for theversions with version numbers 1, 2, and 3 of the file with the file ID1.Here, the initial value of each count value is set to be 0, and theinitial value of each deletion delay flag is set to be false (or a valueindicating false such as “0”).

[0255] In this fifth embodiment, the client 91 makes the editing startdeclaration to the file management server 95 immediately before startingthe editing of the file. This editing start declaration is made bytransmitting a command word indicating that it is the editing startdeclaration, followed by the file ID of the file to be a target of theediting and the version number of the version to be edited, from theclient 91 to the file management server 95, through the communicationpath 111.

[0256] The communication data received by the file management server 95are then entered into the branching unit 901. At the branching unit 901,the first one word of the communication data is read out, and when it isjudged that it is the command word indicating that it is the editingstart declaration, the following file ID and the version number in thecommunication data are entered into the editing start processing unit902.

[0257] At the editing start processing unit 902, when the input from thebranching unit 901 is received, an access to the count memory unit 905is made to increase the count value corresponding to the specifiedversion of the specified file ID by one.

[0258] On the other hand, the communication data received at thebranching unit 901 are also given to the record management unit 510either as they are or as the file ID and the version number areprocessed appropriately. Then, after the editing start declaration isprocessed as described above, the editing of the file by the client 91is carried out, At this point, the file editing mechanism is similar tothat in the configuration of FIG. 13 described above.

[0259] Next, a processing mechanism for a case of deleting a version ofa file will be described, In this fifth embodiment, the version deletionrequest is also made by transmitting a command word indicating that itis the version deletion request, followed by the file ID of the file tobe a target of the deletion and the version number of the version to bedeleted, from the client 91 to the file management server 95, throughthe communication path 111.

[0260] The communication data received by the file management server 95are then entered into the branching unit 901. At the branching unit 901,the first one word of the communication data is read out, and when it isjudged that it is the command word indicating that it is the versiondeletion request, the following file ID and the version number in thecommunication data are entered into the deletion request processing unit903.

[0261] At the deletion request processing unit 903, when the input fromthe branching unit 901 is received, the processing according to the flowchart of FIG. 28 is carried out as follows.

[0262] At the deletion request processing unit 903, the count memoryunit 905 is accessed first, and the count value C for the specifiedversion number of the specified file ID is obtained (step S21).

[0263] Next, whether that count value C is equal to 0 or not is judged(step S22). When that count value C is equal to 0, the command fordeleting the specified version of the specified file is issued from thedeletion command issuing unit 906 to the record management unit 510(step S23), whereas when that count value C is not equal to 0, the countmemory unit 905 is accessed and the deletion delay flag for thespecified version number of the specified file ID is set to be true (ora value indicating true such as “1”)(step S24).

[0264] Next, the processing at an end of the editing will be described.In this fifth embodiment, the client 91 makes the editing enddeclaration to the file management server 95 immediately after endingthe editing of the file. This editing end declaration is made bytransmitting a command word indicating that it is the editing enddeclaration, followed by the file ID of the file for which the editingis finished and the version number of the version for which the editingis finished, from the client 91 to the file management server 95,through the communication path 111.

[0265] The communication data received by the file management server 95are then entered into the branching unit 901. At the branching unit 901,the first one word of the communication data is read out, and when it isjudged that it is the command word indicating that it is the editing enddeclaration, the following file ID and the version number in thecommunication data are entered into the editing end processing unit 904.Here, whenever necessary, the communication data received at thebranching unit 901 are also given to the record management unit 510either as they are or as the file ID and the version number areprocessed appropriately.

[0266] At the editing end processing unit 904, when the input from thebranching unit 901 is received, the processing according to the flowchart of FIG. 29 is carried out as follows.

[0267] At the editing end processing unit 904, the count memory unit 905is accessed first, and the count value C and the deletion delay flag Ffor the specified version number of the specified file ID is obtained(step S31). Then, that count value C is reduced by one (step S32), andthe resulting count value C is stored into count memory unit 905 (stepS33).

[0268] Next, whether that count value is equal to 0 or not is judged(step S34). When that count value C is not equal to 0, the processing atthe editing end processing unit 904 is finished. On the other hand, whenthat count value C is equal to 0, whether that deletion delay flag F istrue or false is judged (step S35). When that deletion delay flag F isfalse, the processing at the editing end processing unit 904 isfinished. On the other hand, when that deletion delay flag F is true,the command for deleting the specified version of the specified file isissued from the deletion command issuing unit 906 to the recordmanagement unit 510 (step S36).

[0269] It is to be noted that, at the branching unit 901, when the firstone word of the communication data is read out, and when it is judged asnone of the command words for the editing start declaration, the versiondeletion request, and the editing end declaration described above, thecommunication data are entered into the record management unit 510 asthey are.

[0270] Next, an exemplary deletion command execution processing at therecord management unit 510 will be described. Here, the deletion commandprocessing procedure differs depending on which one of the differencepile up scheme, the RCS scheme, and the modified SCCS scheme is used bythe record management unit 510, so that an example for each of thesethree cases will be described one by one.

[0271] In the following explanation, the following symbols will be used.

[0272] r: a version number of the deletion target version

[0273] f: a version number of the oldest version stored by the recordmanagement unit 510 among the records for the target file (In many case,f=1, but when the version 1 had been deleted by the version deletioncommand in the past, f may take a value other than 1)

[0274] n: a version number of the latest version (current version)stored by the record management unit 510 among the records for thetarget file

[0275] p(x): a version number of a version immediately previous to acertain version x among the versions stored by the record managementunit 510 (In many case, p=x−1, but if the version x−1 had been deletedin the past, p=x−2, and if the version x−2 had also been deleted in thepast, p=x−3, and so on)

[0276] s(x): a version number of a version immediately subsequent to acertain version x among the versions stored by the record managementunit 510 (In many case, s=x+1, but if the version x+1 had been deletedin the past, s=x+2, and if the version x+2 had also been deleted in thepast, s=x+3, and so on)

[0277] V[x]: (content of) version x

[0278] V[x]−V[y]: a difference between version x and version y

[0279] First, a case in which the record management unit 510 is carryingout the record management according to the difference pile up schemewill be explained. FIG. 30 shows a flow chart for the deletion commandexecution processing in this case.

[0280] (i) A case in which the deletion target is not the first versionof the records or the current version (a case of r≠f at the step S41 andr≠n at the step S45)

[0281] In this case, the previous version (V[p(r)]) and the subsequentversion (V[s(r)]) of the deletion target version are restored (stepS47), a difference (V[s(r)]−V[p(r)]) between these two versions isobtained (step S48), and the differences (V[s(r)]−V[r]) and(V[r]−V[p(r)]) of the deletion target version with respect to itsprevious and subsequent versions are replaced by the obtained difference(V[s(r)]−V[p(r)]) (step S49).

[0282] (ii) A case in which the deletion target is the first version ofthe records (a case of r=f at the step S41)

[0283] In this case, the subsequent version (V[s(r)]) of the deletiontarget version is restored (step S42), the first version (V[r]) of therecords and a difference between the first version and its subsequentversion (V[s(r)]−V[r]) are deleted (step S43), and V[s(r)] is set to bea new first version of the records (step S44).

[0284] (iii) A case in which the deletion target is the last version(current version) of the records (a case of r=n at the step S45)

[0285] In this case, a difference (V[r]−V[p(r)]) between that versionand its previous version is deleted (step S46).

[0286] Next, a case in which the record management unit 510 is carryingout the record management according to the RCS scheme will be explained.FIG. 31 shows a flow chart for the deletion command execution processingin this case.

[0287] (i) A case in which the deletion target is not the first versionof the records or the current version (a case of r≠f at the step S61 andr≠n at the step S65)

[0288] In this case, the previous version (V[p(r)]) and the subsequentversion (V[s(r)]) of the deletion target version are restored (stepS67), a difference (V[p(r)]−V[s(r)]) between these two versions isobtained (step S68), and the differences (V[p(r)]−V[r]) and(V[r]−V[s(r)]) of the deletion target version with respect to itsprevious and subsequent versions are replaced by the obtained difference(V[p(r)]−V[s(r)]) (step S69).

[0289] (ii) A case in which the deletion target is the first version ofthe records (a case of r=f at the step S61)

[0290] In this case, a difference (V[r]−V[s(r)]) between that versionand its previous version is deleted (step S62).

[0291] (iii) A case in which the deletion target is the last version(current version) of the records (a case of r=n at the step S63)

[0292] In this case, the previous version (V[p(r)]) of the currentversion is restored (step S64), a difference between the current versionand its previous version (V[p(r)]−V[r]) is deleted (step S65), andV[p(r)] is set to be a new current version (step S66).

[0293] Next, a case in which the record management unit 510 is carryingout the record management according to the modified SCCS scheme will beexplained. FIG. 32 shows a flow chart for the deletion command executionprocessing in this case. Here, the flow chart of FIG. 32 shows thedeletion processing procedure for one block constituting the record. Thedeletion processing at the record management unit 510 is carried out byapplying this procedure to all the blocks which contain the deletiontarget version.

[0294] In the following explanation, the following symbols will also beused.

[0295] i: a creation time of a block which is a processing target

[0296] d: a deletion time of a block which is a processing target

[0297] Here, the block which is not yet deleted even in the currentversion will be designated by d=∞.

[0298] (i) A case in which the deletion target is not the currentversion (a case of r≠n at the step S81)

[0299] In this case, for those blocks which existed only in the deletiontarget version (i=r at the step S85 and d=s(r) at the step S86), theseblocks are deleted from the record data (step S90).

[0300] For those blocks which are created in the deletion target version(i=r at the step S85 and d≠s(r) at the step S86), these blocks areregarded as created in the subsequent version (V[s(r)]) of the deletiontarget version (step S87).

[0301] For those blocks which are deleted in the deletion target version(i≠r at the step S85 and d=r at the step S88), these blocks are regardedas deleted in the subsequent version (V[s(r)]) of the deletion targetversion (step S89).

[0302] (ii) A case in which the deletion target is the current version(a case of r=n at the step S81)

[0303] In this case, for those blocks which are created in the currentversion (i=n at the step S82), these blocks are deleted from the recorddata (step S90).

[0304] For those blocks which are deleted in the current version (i≠n atthe step S82 and d=n at the step S83), these blocks are regarded as theblocks which have not been deleted (d=∞) (step S84).

[0305] Here, after the above processing is applied to all the blocks,for arbitrary neighboring two blocks in the records, if they have theidentical creation time and the identical deletion time, these twoblocks may be united together.

[0306] It is to be noted that, in the above, a case of deleting oneversion by one deletion command has been explained, but even in thegeneral version management system, by processing the deletion requestfor a plurality of versions by decomposing it into a plurality ofdeletion commands for each one of the target versions, it is easy toobtain the similar effect as providing a function to delete a pluralityof versions by one deletion command,

[0307] As described, according to this fifth embodiment, a number ofclients who are editing each version of each file is stored for eachversion of each file, and the execution of the deletion is delayed untilno client remains to be editing the deletion target version of thetarget file, even when there is a request for deleting that version ofthat file from the user, so that no client can delete the version duringthe editing, and therefore it is possible to realize the asynchronousediting system in which the merge processing can be executed without atrouble.

[0308] Here, the deletion of the record in this fifth embodiment hasbeen made as the deletion request is issued from the client to the filemanagement server, but it is also possible to consider a configurationin which the deletion request is generated from element other than theclient. For example, for any record for which a prescribed period oftime has elapsed since its creation, the deletion request can begenerated automatically within the server, Also, in a case it issufficient to support the asynchronous editing for the latest versionalone, and no editing for the past versions is included, it suffices touse a configuration in which the deletion request for a previous versionis generated automatically within the server at a timing of a creationof a new version.

[0309] It is to be noted that this fifth embodiment has been a case inwhich the client counting unit is added to a configuration of FIG. 13 inwhich the file content secrecy function and the asynchronous editingfunction are implemented on the client server type system, but it isalso possible to add the client counting unit to a configuration of FIG.16 or FIG. 20 in which the asynchronous editing function is implementedon the client server type system. In such a case, a configuration and afunction of the client counting unit can be substantially the same asdescribed above for a case of using a configuration of FIG. 13.

[0310] Next, the sixth embodiment of a shared file editing systemaccording to the present invention will be described in detail. In thissixth embodiment, the shared file editing system of FIG. 13, FIG. 16, orFIG. 20 described above is further equipped, when the block data of acertain file are enciphered, with a function for delaying an executionof a deletion of a version in response to a deletion request for acertain version of a certain file, until no client remains to be editingthat certain version of that certain file as in FIG. 25 described above,and an additional function for reconstructing the block data of thatcertain file.

[0311] As mentioned above, in the system employing the recordmanagement, it is possible to provide a function for deleting someversions among the records. This sixth embodiment provides a functionfor deleting the record of a certain version when the block data areenciphered. In addition, this sixth embodiment also provides a functionfor reducing a number of blocks by reconstructing the block data.

[0312] In order to realize such additional functions, in this sixthembodiment, the client is provided with means for reconstructing theblock data of the file. By this means, the client can delete the recordof a certain version and reconstruct the file data into the desiredblocks.

[0313]FIG. 33 shows a configuration of the shared file editing system ofthis sixth embodiment as outlined above, which is based on the sharedfile editing system of FIG. 25 described above.

[0314] In this configuration of FIG. 33, the file management server 95and the communication path 111 are substantially similar as those inFIG. 25. Each access requesting client 92 differs from that of FIG. 25in that it further includes a block data reconstruction unit 910. Here,this block data reconstruction unit 910 may not necessarily be providedin every one of the clients 92 of the system. Thus, in this sixthembodiment, the version deletion request for a certain file is executedwhen the count value of the client counting unit 900 is equal to 0, justas in the fifth embodiment described above.

[0315] Now, an exemplary execution processing for deleting the record ofa certain version in a case the block data are enciphered will beexplained. Here, the version deletion processing procedure differsdepending on which one of the difference pile up scheme, the RCS scheme,and the modified SCCS scheme is used by the record management unit 510,so that an example for each of these three cases will be described oneby one.

[0316] In the following explanation, the following symbols will be used.

[0317] r: a version number of the deletion target version

[0318] f: a version number of the oldest version stored by the recordmanagement unit 510 among the records for the target file (In many case,f=1, but when the version 1 had been deleted by the version deletioncommand in the past, f may take a value other than 1)

[0319] n: a version number of the latest version (current version)stored by the record management unit 510 among the records for thetarget file

[0320] p(x): a version number of a version immediately previous to acertain version x among the versions stored by the record managementunit 510 (In many case, p=x−1, but if the version x−1 had been deletedin the past, p=x−2, and if the version x−2 had also been deleted in thepast, p=x−3, and so on)

[0321] s(x): a version number of a version immediately subsequent to acertain version x among the versions stored by the record managementunit 510 (In many case, s=x+1, but if the version x+1 had been deletedin the past, s=x+2, and if the version x+2 had also been deleted in thepast, s=x+3, and so on)

[0322] V[x]: (content of) version x

[0323] V[x]−V[y]: a difference between version x and version y

[0324] First, a case in which the record management unit 510 is carryingout the record management according to the difference pile up schemewill be explained. FIG. 34 shows a flow chart for the processingprocedure at the block data reconstruction unit 910 in the client 92 inthis case, while FIG. 35 shows a flow chart for the processing procedureat the record management unit 510 in the server 95 which received thedeletion request from the client 92 in this case.

[0325] First, the processing procedure of the client 92 will bedescribed with reference to FIG. 34.

[0326] (i) A case in which the deletion target is not the first versionof the records or the current version (a case of r≠f at the step S101and r≠n at the step S106)

[0327] In this case, the subsequent version (V[s(r)]) of the deletiontarget version is read out from the server 95 (step S108). Here, (aplurality of) enciphered block data are transmitted from the server 95.

[0328] Then, the transmitted block data are deciphered by the cipherunit 112, and the subsequent version (V[s(r)]) and the previous version(V[p(r)]) of the deletion target version are restored (step S109). Here,V[p(r)] can be obtained from V[s(r)] read out at the step S108.

[0329] Then, a difference (V[s(r)]−V[p(r)]) between these two versionsis obtained (step S110).

[0330] Then, the obtained difference (V[s(r)]−V[p(r)]) is enciphered bythe cipher unit 112 as a new block data (step S111).

[0331] Finally, this enciphered block data and the deletion request forthe version r are transmitted to the server 95 (step S112).

[0332] (ii) A case in which the deletion target is the first version ofthe records (a case of r=f at the step S101)

[0333] In this case, the subsequent version (V[s(r)]) of the deletiontarget version is read out from the server 95 (step S102). Here, (aplurality of) enciphered block data are transmitted from the server 95.

[0334] Then, the transmitted block data are deciphered by the cipherunit 112, and the subsequent version (V[s(r)]) of the deletion targetversion is restored (step S103).

[0335] Then, the obtained (V[s(r)]) is enciphered by the cipher unit 112as a new block data (step S104).

[0336] Finally, this enciphered block data and the deletion request forthe version r are transmitted to the server 95 (step S105).

[0337] (iii) A case in which the deletion target is the last version(current version) of the records (a case of r=n at the step S106)

[0338] In this case, the deletion request for the version r istransmitted to the server 95 (step S107).

[0339] Next, the processing procedure of the server 95 which receivedthe deletion request from the client 92 will be described with referenceto FIG. 35.

[0340] (i) A case in which the deletion target is not the first versionof the records or the current version (a case of r≠f at the step S121and r≠n at the step S123)

[0341] In this case, a block data (V[s(r)]−V[r]) and a block data(V[r]−V[p(r)]) are deleted, and a block data (V[s(r)]−V[p(r)])transmitted from the client 92 is inserted instead (step S125).

[0342] (ii) A case in which the deletion target is the first version ofthe records (a case of r=f at the step S101)

[0343] In this case, a block data V[r] and a block data (V[s(r)]−V[r])are deleted, and a block data (V[s(r)] transmitted from the client 92 isinserted instead (step S122).

[0344] (iii) A case in which the deletion target is the last version(current version) of the records (a case of r=n at the step S106)

[0345] In this case, a block data (V[r]−V[p(r)]) is deleted (step S124).

[0346] By the above procedure, the record of the version r can bedeleted.

[0347] Next, a case in which the record management unit 510 is carryingout the record management according to the RCS scheme will be explained.FIG. 36 shows a flow chart for the processing procedure at the blockdata reconstruction unit 910 in the client 92 in this case, while FIG.37 shows a flow chart for the processing procedure at the recordmanagement unit 510 in the server 95 which received the deletion requestfrom the client 92 in this case.

[0348] First, the processing procedure of the client 92 will bedescribed with reference to FIG. 36.

[0349] (i) A case in which the deletion target is not the first versionof the records or the current version (a case of r≠f at the step S131and r≠n at the step S133)

[0350] In this case, the previous version (V[p(r)]) of the deletiontarget version is read out from the server 95 (step S138). Here, (aplurality of) enciphered block data containing the latest version aretransmitted from the server 95.

[0351] Then, the transmitted block data are deciphered by the cipherunit 112, and the subsequent version (V[s(r)]) and the previous version(V[p(r)]) of the deletion target version are restored (step S139). Here,V[s(r)] can be obtained from V[p(r)] read out at the step S138.

[0352] Then, a difference (V[p(r)]−V[s(r)]) between these two versionsis obtained (step S140).

[0353] Then, the obtained difference (V[p(r)]−V[s(r)]) is enciphered bythe cipher unit 112 as a new block data (step S141).

[0354] Finally, this enciphered block data and the deletion request forthe version r are transmitted to the server 95 (step S142).

[0355] (ii) A case in which the deletion target is the first version ofthe records (a case of r≠f at the step S131)

[0356] In this case, the deletion request for the version r istransmitted to the server 95 (step S132).

[0357] (iii) A case in which the deletion target is the last version(current version) of the records (a case of r≠n at the step S133)

[0358] In this case, the previous version (V[p(r)]) of the deletiontarget version is read out from the server 95 (step S134). Here, (aplurality of) enciphered block data containing the latest version aretransmitted from the server 95.

[0359] Then, the transmitted block data are deciphered by the cipherunit 112, and the previous version (V[p(r)]) of the deletion targetversion is restored (step S135).

[0360] Then, the obtained (V[p(r)]) is enciphered by the cipher unit 112as a new block data (step S136).

[0361] Finally, this enciphered block data and the deletion request forthe version r are transmitted to the server 95 (step S137).

[0362] Next, the processing procedure of the server 95 which receivedthe deletion request from the client 92 will be described with referenceto FIG. 37.

[0363] (i) A case in which the deletion target is not the first versionof the records or the current version (a case of r≠f at the step S151and r≠n at the step S153)

[0364] In this case, a block data (V[r]−V[s(r)]) and a block data(V[p(r)]−V[r]) are deleted, and a block data (V[p(r)]−V[s(r)])transmitted from the client 92 is inserted instead (step S155).

[0365] (ii) A case in which the deletion target is the first version ofthe records (a case of r≠f at the step S151)

[0366] In this case, a block data (V[r]−V[S(r)]) is deleted (step S152).

[0367] (iii) A case in which the deletion target is the last version(current version) of the records (a case of r≠n at the step S153)

[0368] In this case, a block data V[r] and a block data (V[p(r)]−V[r])are deleted, and a block data V[p(r)] transmitted from the client 92 isinserted instead (step S154).

[0369] By the above procedure, the record of the version r can bedeleted.

[0370] Next, a case in which the record management unit 510 is carryingout the record management according to the modified SCCS scheme will beexplained. As mentioned above, in the modified SCCS scheme, the blocksare sequentially divided as the version progresses. When the number ofblocks increases, the overhead due to the block identificationinformation and the block processing increases, so that it is preferablenot to allow a number of blocks to increase too much.

[0371] As shown in FIG. 32, in a case of carrying out the recordmanagement by the modified SCCS scheme, the record management unit 510of the server 95 can execute the version record deletion command.Consequently, it is possible to use a configuration in which the versiondeletion is carried out by the record management unit 510 of the server95, while the block reconstruction is carried out by the block datareconstruction unit 910 of the client 92. In such a case, the processingprocedure is as follows.

[0372] The client 92 transmits the deletion command for the version r tothe server 95 first.

[0373] Then, the record management unit 510 of the server 95 deletes therecord of the version r by the procedure of FIG. 32.

[0374] Then, the client 92 reads out the files of V[s(r)] or V[n], andcarries out the block reconstruction at the block data reconstructionunit 910 and the enciphering at the cipher unit 112, and then returnsthe reconstructed block data to the server 95. Here, the block data thatcan be reconstructed are those block data which are continuous in theirpositions and which have the identical creation time and deletion time.After these blocks are deciphered, they are reconstructed and encipheredas an arbitrary new block data, and then transmitted to the server 95.

[0375] Finally, the record management unit 510 of the server 95 replacesthe old block with the transmitted new block data.

[0376] It is to be noted that the feature for reconstructing the blockdata according to this sixth embodiment may be incorporated into thefile editing system with the file content secrecy feature alone such asthat of FIG. 23 described above.

[0377] Next, the seventh embodiment of a shared file editing systemaccording to the present invention will be described in detail. In thisseventh embodiment, the shared file editing system of FIG. 13, FIG. 16,or FIG. 20 described above is further equipped with an additionalfunction which enables the client who already possesses a certainversion of a certain file to read out only necessary portion of anotherversion newly, rather than reading the entire file of that anotherversion.

[0378]FIG. 38 shows a configuration of the shared file editing system ofthis seventh embodiment as outlined above, which is based on the sharedfile editing system of FIG. 13 described above.

[0379] In this configuration of FIG. 38, the communication path 111 issubstantially similar as that in FIG. 13. The file management server 96differs from that of FIG. 13 in that it further includes a differenceinformation construction unit 930, while each access requesting client93 differs from that of FIG. 13 in that it further includes a filememory unit 920 and a file data construction unit 921.

[0380] The client 93 stores the previously accessed file along with itsversion information in the file memory unit 920. In a case of readingout another version (such as the latest version) of the same file fromthe server 96, the client 93 notifies the currently possessed versioninformation and the desired version information to the server 96. Then,the difference information construction unit 930 of the server 96constructs the difference data between the desired version and thealready possessed version according to the above two versioninformations notified from the client 93, and returns the constructeddifference data to the client 93. Then, the file data construction unit921 of the client 93 constructs the desired version from the currentlypossessed file data and the difference data transmitted from the server96. Then, the constructed desired version is handed over to the sharedfile editing unit 122 for carrying out the editing with respect to thedesired version.

[0381] In general, the difference data between versions are smaller thanthe data of the entire file, so that the amount of communication datacan be reduced, and the high speed read out operation can be realized inthis seventh embodiment.

[0382] Here, a method for constructing the difference data at thedifference information construction unit 930 of the server 96 differsdepending on which one of the difference pile up scheme, the RCS scheme,and the modified SCCS scheme is used by the record management unit 510,so that an example for each of these three cases will be described oneby one.

[0383] In the following explanation, the following symbols will be used.

[0384] c: a version number of the file already possessed by the client93

[0385] r: a version number of a desired version to be newly read out bythe client 93

[0386] V[x]: (content of) version x

[0387] V[x]−V[y]: a difference between version x and version y

[0388] First, the processing procedure for, the difference informationconstruction unit 930 in a case in which the record management unit 510is carrying out the record management according to the difference pileup scheme will be explained.

[0389] (i) A case of reading out a version newer than the alreadypossessed version (r>c)

[0390] In this case, as the difference pile up scheme is a scheme whichpiles up the difference between versions, it suffices to select thedifference block data between the version r and the version c.

[0391] (ii) A case of reading out a version older than the alreadypossessed version (r<c)

[0392] In this case, the following two methods are available.

[0393] (a) V[r] is repeated without constructing the difference data.

[0394] In a case the block data are enciphered, the server cannotconstruct the difference data, so that this method should be employed.

[0395] (b) The server restores V[r] and V[c], and obtains V[r]−V[c].

[0396] This method is possible when the block data are not enciphered.

[0397] Next, the processing procedure for the difference informationconstruction unit 930 in a case in which the record management unit 510is carrying out the record management according to the RCS scheme willbe explained. FIG. 31 shows a flow chart for the deletion commandexecution processing in this case.

[0398] (i) A case of reading out a version newer than the alreadypossessed version (r>c)

[0399] In this case, the following two methods are available.

[0400] (a) V[r] is repeated without constructing the difference data.

[0401] In a case the block data are enciphered, the server cannotconstruct the difference data, so that this method should be employed.

[0402] (b) The server restores V[r] and V[c], and obtains V[r]−V[c].

[0403] This method is possible when the block data are not enciphered.

[0404] (ii) A case of reading out a version older than the alreadypossessed version (r<c)

[0405] In this case, as the RCS scheme is a scheme which leaves thedifference between versions in backward direction as a record, itsuffices to select the difference block data between the version r andthe version c.

[0406] Next, the processing procedure for the difference informationconstruction unit 930 in a case in which the record management unit 510is carrying out the record management according to the modified SCCSscheme will be explained. FIG. 39 shows a flow chart for the processingprocedure for the difference information construction unit 930 to selectthe difference block from the blocks constituting the record of thefile. Here, the flow chart of FIG. 39 shows the difference blockselection processing procedure for one block constituting the record.The difference block selection processing at the difference informationconstruction unit 930 is carried out by applying this procedure to allthe blocks.

[0407] In the following explanation, the following symbols will also beused.

[0408] i: a creation version number of a block which is a processingtarget

[0409] d: a deletion version number of a block which is a processingtarget

[0410] Here, the block which is not yet deleted will be designated byd=NULL.

[0411] (i) A case of reading out a version newer than the alreadypossessed version (r>c at the step S161)

[0412] In this case, a block satisfying either one of the following twoconditions is selected (step S167).

[0413] (a) A block which has been created during a period from theversion c to the version r, and which has not been deleted at a time ofthe version r, i.e., (r≧c) and {(r<d) or (d =NULL)} (step S162).

[0414] (b) A block which had already been created at a time of theversion c and which had been deleted during a period from the version cto the version r, i.e., (i≦c) and (r≧d>c) (step S163).

[0415] (ii) A case of reading out a version older than the alreadypossessed version (r<c at the step S164)

[0416] In this case, a block satisfying either one of the following twoconditions is selected (step S167).

[0417] (a) A block which has been created during a period from theversion r to the version c, and which has not been deleted at a time ofthe version c, i.e., (r<i ≦c) and {(d<c) or (d=NULL)} (step S165).

[0418] (b) A block which had already been created at a time of theversion c and which had been deleted during a period from the version rto the version c, i.e., (i≧c) and (r<d≦c) (step S166).

[0419] After selecting the difference block by the above procedure, thedifference information construction unit 930 converts the selecteddifference block data into the difference information with respect tothe version already possessed by the client 93, and transmits theobtained change information to the client 93. For example, for theinsertion data, the insertion position with respect to the versionpossessed by the client 93 is obtained and transmitted together with theinsertion block data. For the deletion data, the deletion range withrespect to the version possessed by the client 93 is obtained andtransmitted as it is. By means of this, the client 93 can construct thedesired version easily, and the amount of communication data from theserver 96 to the client 93 can be kept small.

[0420] It is to be noted that the feature for constructing the desiredversion on the client side according to this seventh embodiment may beincorporated into the file editing system with the file content secrecyfeature alone such as that of FIG. 23 described above.

[0421] Next, the eighth embodiment of a shared file editing systemaccording to the present invention will be described in detail. In thiseighth embodiment, the shared file editing system of FIG. 13, FIG. 16,or FIG. 20 described above which has the asynchronous editing functionis further equipped with an additional function for handling theconflict in editing due to asynchronously occurring write operationsfrom a plurality of clients with respect to a certain file.

[0422]FIG. 40 shows a configuration of the shared file editing system ofthis eighth embodiment as outlined above, which is based on the sharedfile editing system of FIG. 16 described above.

[0423] In this configuration of FIG. 40, each access requesting client211 and the communication path 111 are substantially similar as those inFIG. 16. The file management server 220 differs from that of FIG. 16 inthat it further includes an editing conflict detection unit 940.

[0424] In this eighth embodiment, just as in a case of FIG. 16, the datawrite requests from a plurality of the clients 211 occur at varioustimings. At the server 220, the write request from each client 211 isconverted into the position data with respect to the latest version atthat timing by the editing procedure conversion unit 502. Then, at theediting conflict detection unit 940, whether the converted editing datais in conflict with the editing result made by the other clients 211 ornot is detected. The obtained detection result is then returned to thateach client 211.

[0425] Here, the conflict in editing can be judged according to thefollowing criteria for example.

[0426] (a) The insertion position of the insertion data has already beendeleted.

[0427] (b) The insertion position of the insertion data has the otherdata already inserted.

[0428] (c) The deletion range has other data already inserted.

[0429] (d) A part of the deletion range has already been deleted.

[0430] At the record management unit 510, the detection result of theediting conflict detection unit 940 is not received, and the datatransmitted from the client 211 and converted by the editing procedureconversion unit 502 are stored as the latest version.

[0431] Here, the data updating by the server 220 may be possible orimpossible depending on the management scheme used by the recordmanagement unit 510 and whether or not the block data are enciphered. Ina case the block data are not enciphered, the data updating by theserver 220 is possible for any of the difference pile up scheme, the RCSscheme, and the modified SCCS scheme. In a case the block data areenciphered, the data updating by the server 220 is possible only for themodified SCCS scheme.

[0432] Next, the ninth embodiment of a shared file editing systemaccording to the present invention will be described in detail. In thisninth embodiment, the shared file editing system of the eighthembodiment described above is further modified such that the editingconflict detection unit 940 notifies the detection result to the recordmanagement unit 510 and the record management unit 510 judges whether ornot to carry out the data updating according to the notified detectionresult.

[0433]FIG. 41 shows a configuration of the shared file editing system ofthis ninth embodiment as outlined above, which is based on the sharedfile editing system of FIG. 40 described above.

[0434] In this configuration of FIG. 41, each access requesting client211 and the communication path 111 are substantially similar as those inFIG. 40. The file management server 225 differs from that of FIG. 40 inthat the output of the editing conflict detection unit 940 is alsosupplied to the record management unit 510.

[0435] In this ninth embodiment, when the editing conflict with theother clients does not occur, the data transmitted from the client 211and converted by the editing procedure conversion unit 502 are stored asthe latest version, whereas when the editing conflict with the otherclients occurs, the data updating by the server 225 is not carried out.In this case, the latest version to which the writing was actually madecan be known as free of the editing conflict with the other clients, sothat there is an advantage that the contradiction in meaning is unlikelyto occur. The client 211 receives the notification of the detectionresult obtained by the editing conflict detection unit 940, so that in acase the writing was not made, the client 211 can read out the latestversion from the server and carry out a different editing which avoidsthe occurrence of the conflict.

[0436] Next, the tenth embodiment of a shared file editing systemaccording to the present invention will be described in detail. In thistenth embodiment, the shared file editing system is formed such that itcan be utilized from the already existing application program.

[0437]FIG. 42 shows a configuration of the shared file editing system ofthis tenth embodiment as outlined above, which generally comprises aplurality of access requesting clients 950 and a file management server970 which are connected through a communication path 111. The filemanagement server 970 further includes a communication (COMM) unit 131,an access information memory unit 971, a record management unit (forshared file) 972, and a data memory unit 973. Each access requestingclient 950 further includes an access request unit 951, a system calltable 955, a shared file access processing unit 960, and a communication(COMM) unit 130. Each access requesting client 950 and the filemanagement server 970 can communicate through the communication path 111by means of the respective communication (COMM) units 130 and 131.

[0438] In this tenth embodiment, the access request unit 951 is assumedto be the already existing application program, and the access requestissued from the access request unit 951 is to be executed by the systemcall provided by the operating system.

[0439] In this tenth embodiment, the access request unit 951 refers tothe functions corresponding to the system calls listed in the systemcall table 955, and executes one of open/close/read/write functions. Thedata in the system call table 955 which refer to the functions of thesystem calls in the operating system are rewritten from the connectiondata (address pointers) to open function/close function/readfunction/write function provided by the operating system into theconnection data (address pointers) to shared open function/shared closefunction/shared read function/shared write function which are providedby the shared file access processing unit 960. These shared openfunction/shared close function/shared read function/shared writefunction 961 are then transmitted through the communication (COMM) unit130 to the file management server 970.

[0440] Therefore, when the access request unit 951 comprising thealready existing application program executes the open function/closefunction/read function/write function, actually the shared openfunction/shared close function/shared read function/shared writefunction 961 are going to be executed.

[0441] Here, the shared open function/shared close function/shared readfunction/shared write function 961 actually correspond to the processingaccording to the shared file access request for carrying out “open”, theprocessing according to the shared file access request for carrying out“close”, the processing according to the shared file access request forcarrying out “read”, and the processing according to the shared fileaccess request for carrying out “write”, respectively. It is to be notedthat, in FIG. 42, the shared open function/shared close function/sharedread function/shared write function 961 are provided separately, but theprocessing common to all these functions 961 may be provided as oneprocess and shared by these four functions.

[0442] The file management server 970 receives the shared openfunction/shared close function/shared read function/shared writefunction 961 from the access requesting client 950, and hand them to therecord management unit 972. Then, the record management unit 972 cancarry out the reading or the writing of the desired data from the datamemory unit 973 according to the information of the access informationmemory unit 971. Then, the executed access request is recorded as datain the access information memory unit 971.

[0443]FIG. 43 shows an example of the access record list 980 in theaccess information memory unit 971. This access record list 980 is alist for storing the access requests to the files of the file managementserver 970. This access record list 980 has six fields for a file ID981, a mode 982, an open time 983, a close time 984, a version 985, anda current 986.

[0444] The file ID 981 is an identifier uniquely assigned to each sharedfile access request for “open” given from the access request unit 951 tothe record management unit 972. After the “open” request, the sharedfile access requests from the access request unit 951 are managed byusing the file ID 981. This file ID 981 is issued to the access requestunit 951 whenever the shared file access request for “open” is receivedby the record management unit 972.

[0445] The mode 982 indicates a mode of the open request to this file,where “r” indicates that it is read only mode, and “w” indicates that itis either write only mode or read and write mode.

[0446] The open time 983 indicates a time at which the open request tothis file was issued. In this example, the file represented as ID1 isindicated as opened at a time t1. Also, the close time 984 indicates atime at which the close request to this file was issued. In thisexample, the file represented as ID1 is indicated as still open as theclose time 984 is not entered, whereas the file represented as ID2 isindicated as closed at a time t5.

[0447] Here, the time is used to indicate the timing relationship amongthe occurrence times of various events, and may be given by an internalclock of a computer, or the version number used for the file managementmay be utilized as the time. Also, this time is used only by the recordmanagement unit 972, so that there is no need for the other element suchas the access requesting client 950 to be able to refer to this timedirectly.

[0448] The version 985 indicates the version of the file from which theopen request to this file has been issued. Usually, the system call“open” is a request with respect to the latest version, so that thisversion 985 is usually given by the latest version at a time of issuanceof the open request.

[0449] The current 986 is a value (seek pointer) which indicates thecurrently accessed position, for the currently accessing access request.This seek pointer indicates the read out position (relative positionwithin the file) to the shared file access request for “read” whichcomes next. In a case of the “open” in the read only mode, the initialvalue is set to be 0 as a default.

[0450] The record management unit 972 manages the asynchronous accessesfrom the access requesting clients 950, and carries out the read and thewrite of the desired data with respect to the data memory unit 973according to the contents of the access information memory unit 971.Here, the operation of the record management unit 972 itself is similarto that in the previous embodiments described above, so that itsexplanation will be omitted.

[0451] According to this tenth embodiment described above, the alreadyexisting application software program can be utilized as the accessrequesting client for carrying out the asynchronous editing in thissystem, without requiring any change at all in the program itself, bysimply rewriting the values of the address pointers in the system calltable 955 provided by the operating system.

[0452] Next, the eleventh embodiment of a shared file editing systemaccording to the present invention will be described in detail. Thiseleventh embodiment is a modification of the tenth embodiment describedabove, which is aiming at the same purpose as the tenth embodiment.

[0453]FIG. 44 shows a configuration of the shared file editing system ofthis eleventh embodiment, which differs from the configuration of FIG.42 in that the access information memory unit 971 provided in the filemanagement server 970 in FIG. 42 is now provided as the accessinformation memory unit 995 in the access requesting client 990 in FIG.44. In this case, the file management server 90 including the recordmanagement unit 510, the data memory unit 511, and the communication(COMM) unit 131 is substantially similar to that in the configuration ofFIG. 13 described above.

[0454] In this eleventh embodiment, the access requesting client 990stores the shared file access information from its own access requestunit 991 into the access information memory unit 995. The content of theaccess information memory unit 995 can be similar to that shown in FIG.43 described above, for example.

[0455] The shared file access processing unit 993 reads out theinformation in the access information memory unit 995, and transmits therequest to the file management server 90 by adding necessary informationto the shared open function/shared close function/shared readfunction/shared write function 994 as the arguments of the respectivefunctions.

[0456] For example, when the read system call for reading 10 bytes fromthe file with the file ID of ID1 is issued from the access request unit991, the shared file access processing unit 993 reads out the versioninformation 985 and the current position information 986 concerning thefile ID of ID1 from the access information memory unit 995, and addsthese informations along with the file ID of ID1 and the number of bytesto be read out to the argument of the shared open function, and thentransmits it tot he file management server 90.

[0457] The request transmitted from the access requesting client 990 tothe file management server 90 contains the current access information ofthe access requesting client in addition to the usual information givenby the system call of the operating system, so that the recordmanagement unit 510 can take out the desired data from the data memoryunit 511 according to that information.

[0458] As described, even in this eleventh embodiment, the alreadyexisting application software program can be utilized as the accessrequesting client for carrying out the asynchronous editing in thissystem, without requiring any change at all in the program itself, bysimply rewriting the values of the address pointers in the system calltable 992 provided by the operating system.

[0459] It is to be noted that the feature for enabling the use of thealready existing application program with respect to the shared filesaccording to the tenth and evelenth embodiments may be utilized as afeature for enabling the use of the already existing application programwith respect to the enciphered files, by replacing the access functionsfor the shared files in the above description by the access functionsfor the enciphered files, in the file editing system with the filecontent secrecy feature alone such as that of FIG. 23 described above.

[0460] It is also to be noted that, in the various embodiments describedabove, the communication through a communication path betweencommunication units provided on the client and the server may berealized in a form of a network communication between the clientcomputer device and the server computer device, or in a form of a datatransfer between the client program and the server program within asingle computer device.

[0461] It is also to be noted that, besides those already mentionedabove, many modifications and variations of the above embodiments may bemade without departing from the novel and advantageous features of thepresent invention. Accordingly, all such modifications and variationsare intended to be included within the scope of the appended claims.

1-25 (Cancel)
 26. A shared file editing system, comprising: a filemanagement server device for managing files, each file containing aplurality of block data and block identification information for eachblock data; a plurality of client devices, each client device making anaccess to the file management server device to obtain the block datacorresponding to a desired version of a desired file managed by the filemanagement server device, and editing the desired file formed by theblock data obtained from the file management server device; andasynchronous editing support means for supporting asynchronous editingby said plurality of client devices, including: editing proceduregeneration means for generating editing procedure data indicating aprocedure to obtain each editing made in the desired file by each clientdevice; editing procedure conversion means for converting the editingprocedure data for the desired version of the desired file generated bythe editing procedure generation means into editing procedure data for alatest version of the desired file; and record management informationgeneration means for generating record management information indicatinga result of the editing made in the desired file by each client device,according to the editing procedure data for the latest version of thedesired file obtained by the editing procedure conversion means, suchthat the file management server device manages the desired fileaccording to the record management information and the blockidentification information for each block data.
 27. The system of claim26, wherein the file management server device includes; client countingmeans for counting a number of client devices which are currentlyediting each version of each file, in correspondence to each version ofeach file managed by the file management server device; and deletiondelay means for delaying an execution of a deletion of a particularversion of a particular file in response to a request for deleting theparticular version of the particular file until said number of clientdevices counted by the client counting means becomes zero.
 28. Thesystem of claim 28, wherein each client device includes: block datareconstruction means for reconstructing a plurality of block dataobtained from the file management server device into a new block data;and wherein each client device transmits the new block data obtained bythe block data reconstruction means to the file management serverdevice, such that the file management server device manages the desiredfile according to the new block data received from the client device.29. The system of claim 26, wherein each client device includes: filememory means for storing a previously accessed version of the desiredfile; and file data construction means for constructing a desiredversion of the desired file according to the previously accessed versionstored in the file memory means and the block data belonging to thedesired file which are obtained from the file management server device;and wherein the file management server device includes: differenceconstruction means for constructing the block data to be given to theclient device by obtaining difference between the previously accessedversion and the desired version.
 30. The system of claim 26, wherein thefile management server device includes: editing conflict detection meansfor detecting an occurrence of a conflict between an editing made by oneclient device and another editing made by another client device, andnotifying the detected occurrence of the conflict to said one clientdevice.
 31. The system of claim 30, wherein the file management serverdevice further includes: record management means for carrying out arecord management of the desired file according to the record managementinformation obtained by the asynchronous editing support means for saidone client device, only when the editing conflict detection means doesnot detect the occurrence of the conflict for said one client device.32. The system of claim 26, wherein each client device includes: accessrequest means for issuing an access request in terms of system callsprovided by an operating system, with respect to a shared file managedby the file management server device; system call table means forregistering address pointers corresponding to the system calls; andshared file access processing means for obtaining a shared file accessrequest to be transmitted from each client device to the file managementserver device, according to the address pointers registered in thesystem call table means corresponding to the system calls specified bythe access request issued at the access request means. 33-35 (Cancel)36. A method of shared file editing in a shared file editing systemformed by a file management server device and a plurality of clientdevices, comprising the steps of: managing files at the file managementserver device, each file containing a plurality of block data and blockidentification information for each block data; making an access to thefile management server device to obtain the block data corresponding toa desired version of a desired file managed by the file managementserver device, at each client device; editing the desired file formed bythe block data obtained from the file management server device, at eachclient device; generating editing procedure data indicating a procedureto obtain an editing made in the desired file by each client device atthe editing step; converting the editing procedure data for the desiredversion of the desired file obtained at the editing procedure datagenerating step into editing procedure data for a latest version of thedesired file; and generating record management information indicating aresult of the editing made in the desired file by each client device atthe editing step, according to the editing procedures data for thelatest version of the desired file obtained by the converting step, suchthat the file management server device manages the desired fileaccording to the record management information and the blockidentification information for each block data.